On Mon, 28 Jan 2013, Alexander Klenin wrote:
On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt
<[email protected]> wrote:
On Mon, 28 Jan 2013, Alexander Klenin wrote:
I have a compromise suggestion:
Implement for-index extension with the syntax:
for (k, v) in a do
this syntax is forward-compatible with both tuples proposals,
is simple to do (basically, already done -- only a small change in
parsing is required)
what concerns syntax, I have no problem with this.
What bothers me immensely is the same what bothered me in the totally
braindead
Delphi implementation of the "for in" loop : the bunch of requirements you
put on the iterator implementation: an interface with special status. You
can't get more stupid and ugly than that.
Out of curiosity -- how would you implement it?
Define an iterator type/operator.
- No interface
- No 'specially named function' in the class. The iterator should be separate
from the class.
Now they promoted 1 function with a special name to a special status:
'GetEnumerator'
(I know this is how Python and so did it, but I'm not particularly fond of that
either).
(Except "the Oberon way" -- by telling the programmer that he is
better off without this feature :-))
I am still not convinced that language support for iterators are needed.
You may be bothered by the various loop methods in the rtl/fcl.
But I am not in the least bothered by it.
I have no particular like or dislike for the Delphi's enumerable implementation,
but it is quite similar to for-in iterators in most other compiled languages.
Well, I do not like to give special status to certain functions or interfaces.
All identifiers should be equal for the law :-)
I was horribly disappointed when they introduced that.
Your initial proposal makes it even worse by adding more conditions to the
interface, it would not even be an interface any more.
I am not sure what are you talking about. Interface is a list of methods.
My for-in proposal would add a new interface (with a single method)
which, if supported by enumerator, would allow user to write for-in-index loops.
I know. I just do not like the approach.
Probably because I don't particularly like interfaces themselves.
That is why I think you need a proper "tuple" value to solve this.
it gives a more fundamental solution: the loop variable type equals the type
returned by the iterator/enumerator. No messing with index (bad syntax) and
even worse: special 'interfaces' and whatnot.
I agree that "index" keyword was perhaps not optimal choice.
Quick, we should call the newspaper, we agree on something ;-)
New interface is needed anyway to preserve backwards compatibility
(and efficiency for the case when the key is not needed).
"Do not slow down existing code".
Yes.
Pascal is a strongly typed language. So, if we absolutely must solve this:
introduce a proper type. A tuple fits the job.
So does the record -- tuple is needed here only to deconstruct that
record in separate variables.
True.
Which begs the question why you didn't use a record to begin with.
I still do not see why the enumerator could not simply return a record
record
key : tkey;
value : tactualtype
end;
for r in myclass do
begin
Writeln(r.key);
With r.value do
end.
to recapitulate:
The construction with interface/index is really very ugly in my opinion,
and I would very much regret it if it became part of Object Pascal.
I can understand the need to have simpler variables.
So a tuple and/or a record deconstructor comes in naturally.
I think a tuple as a type construct may have value in itself.
and as such would prefer to see it as a 'first class citizen' of Object Pascal,
just as it is in e.g. Python, and to a lesser degree, other languages.
The exact details are for me less important.
A small word:
Like most people here I think Pascal is an elegant language, easy to read
and whatnot. It was meant/designed as such, and Wirth did a good job.
I am very passionate about that, I'm sure you noticed. I may use
exuberant language, and probably bad humor, in my efforts to defend it.
Despite that, please do not make the mistake of thinking that I would stop
features just because I do not like them. That said, I will zealously defend
possible alternatives that I think add to the elegance and readability of Pascal.
(as witnessed by the discussions this weekend...)
Borland did a world of good for (Object) Pascal, up to Delphi 7.
After that, it went seriously downhill in my opinion;
Adding randomly features without clear direction or regard for the
intent and philosophy of the Pascal language - or so it seems to me.
Like a ship at the mercy of the waves...
I would be very sorry to see that happening to Free Pascal.
Michael.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
