June 23, 2014
Maybe this is the blogs of the month, but anyway, here is another edition.
Maybe this is the blogs of the month, but anyway, here is another edition of this collection of relevant blog posts. The most relevant news was the release of Update 2 for XE6 and of Appmethod.
Technical Blog Posts
Non-Tech or Non-Delphi
That's all for these few weeks. Trying to get more regular, but no promise.
posted by
marcocantu @ 11:04AM | 4 Comments
[0 Pending]
Delphi Blogs of the Week 14
"The most relevant news was the release of Update 2
for XE6 end of Appmethod". Too soon?
Comment by Gilberto on June 24, 02:50
Delphi Blogs of the Week 14
Gilberto, fixed thanks (end -> and).
Comment by Marco Cantu
[http://www.marcocantu.com]
on June 24, 08:00
Delphi Blogs of the Week 14
Marco, Malcolm did a nice job on the code in question
but it has little resemblance to an actual tuple type.
Tuples can have their values referenced by index, such
as tuple[0], tuple[1], etc. This isn't shown in
Malcolm's examples; they use hardcoded names (e.g.
"Value1"). Tuples can be iterated through in languages
with tuples and iteration; this also isn't demonstrated.
The core benefit of tuples are automatic packing and
unpacking of values. For instance, if "a" and "b" were
existing integer variables, in Oxygene one could write:
(a, b) := SomeFunction();
In python the parentheses are optional and one could,
for instance, on splitting a string write:
first_name, last_name = name.split(' ')
Malcolm's tuples won't help with this either. One also
needs to create a new generic function for every
specific number of parameters (his library includes
two and three items), which is also a hindrance.
As for the reasons it might be useful, he cites
returning more than one value from a function.
Delphi/Pascal already has a means to do this: records.
And the other benefit, "store pairs of values in a
collection" is served by a dictionary.
I believe Malcolm's code has value but that he doesn't
realize what it truly is. :-) What he's created is a
nice piece of syntactic sugar for creating *records*.
The real benefit was in his initialization line, which
he somehow failed to appreciate:
LTuple := TTuple<Integer, String>.Create(10, 'Hello');
This is a nice way to initialize moderately sized
records in a single line of code without repetition or
a with statement. Viewed in that light, it's
reasonably useful. It's just wrong to think of it as a
tuple rather than a record since his creation has all
of the properties of records (including reference by
name, not common in tuples) and none of the important
ones of tuples (index, iteration, unpacking).
I'm a little disappointed by continuing to serve as a
collection point for articles critical of Swift or
other languages given your employer. To the best of my
knowledge, no one at Apple ran a blog post about
Delphi's 32bit performance regression related to
inlining (QC 124652). An article directly comparing
Delphi to another language would be an exception (and
actually be welcomed; such are hard to find and often
out of date).
Comment by Joseph on June 27, 00:10
Delphi Blogs of the Week 14
Joseph,
thanks for the feedback about the tuples, I agree this is a light
solution, compared to full language support, and I think that's an
interesting area for extending the language.
As for being a "collection point of article critical to Swift" I'm sorry
if I gave that impression. I have posted links to both articles
praising the language and indicating some open issues over the
past weeks. I have also indicated that there are some very nice
features in the language, which is a step forward from ObjectiveC.
While I know there is no point in denying issues Delphi and Object
Pascal might have, it is also important to underline their strengths
compared to other solutions, and there are more than it first
appears.
-Marco
Comment by Marco Cantu
[http://www.marcocantu.com]
on June 27, 06:42
There are currently 0 pending (unapproved) messages.