Alexander Klenin wrote:
I support this -- it is awkward for me to test the branch, since it is
not mirrored in Mercurial,
but I will test once it hits the mirror.
Ok, the feature is merged to the trunk now.
Best regards,
Paul Ishenin.
___
fpc-devel
On Sun, Nov 1, 2009 at 17:49, Paul Ishenin wrote:
> If nobody want to test/review and nobody argue then maybe we can merge the
> changes? The changes are made so that they almost does not affect the other
> compiler/rtl code. Therefore there is no risk for the trunk compiler/rtl to
> be broken by
Paul Ishenin wrote:
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
At the moment implementation is almost complete and it is possible to
test and review it (although many checks still needs to be added). It
unites 2 approaches: delphi -
Vinzent Hoefler wrote:
Suppose, the list items have a property "Owner" and the iterator calls
some method that says "Owner.Delete (self);" somewhere. How's the
compiler supposed to detect that?
It can't. In general, all references to the (iterator) list need to be
"const" at this time, but I
On Monday 26 October 2009, Micha Nelissen wrote:
> Vinzent Höfler wrote:
> > At first, "const function" would tell us that the function does not
> > change the object in any way, right?
>
> What is "the object"?
In that case, the list, of course.
> Usually there are 2 objects: the list (TList
>
Vinzent Höfler wrote:
At first, "const function" would tell us that the function does not change the
object in any way, right?
What is "the object"? Usually there are 2 objects: the list (TList e.g.)
and the object being iterated, e.g. TList.Objects[I]. Those referenced
objects can be volati
Micha Nelissen :
> Vinzent Höfler wrote:
> > Von: Micha Nelissen
> >> That's why I suggested the use of 'const functions' in other message in
> >> this thread.
> >
> > Yes, I read that later on. Is that implemented in FPC?
>
> I don't think so; but I think it would be a useful part of the iter
On 25/10/2009, Paul Ishenin wrote:
> I already created delphi compatible enumerator classes for the basic RTL
> lists: TFpList, TList, TStrings, TComponent and TCollection. We can inherit
> all them from the TInterfacedObject and Graeme interfaces. And list classes
> will have 2 methods: GetEnume
Alexander Klenin wrote:
AFAIU, the whole point of the previous discussion is
that you do not have to implement "GetIterator" separately
from "GetEnumerator" -- you can have the same class filling both roles.
Yes. I think we can use some common interfaces/classes/objects in RTL
both for the fo
On Sun, Oct 25, 2009 at 20:05, Graeme Geldenhuys
wrote:
> On 25/10/2009, Alexander Klenin wrote:
>>
>> IMHO, Reset/JumpToBack should not be used inside "for..in" loop -- they are
>> analogous to "goto" inside for loop.
>> If "for .. in .. index" extension is implemented, it may be used to call
On 25/10/2009, Vincent Snijders wrote:
>
> I would call it PeekNext, PeekPrevious, ...
You are correct...
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
On 25/10/2009, Alexander Klenin wrote:
>
> IMHO, Reset/JumpToBack should not be used inside "for..in" loop -- they are
> analogous to "goto" inside for loop.
> If "for .. in .. index" extension is implemented, it may be used to call
As I explained in my previous reply to Paul - I did not
On 25/10/2009, Alexander Klenin wrote:
>
> IMHO, Reset/JumpToBack should not be used inside "for..in" loop -- they are
> analogous to "goto" inside for loop.
> If "for .. in .. index" extension is implemented, it may be used to call
As I explained in my previous reply to Paul - I did not expec
Graeme Geldenhuys schreef:
use, like: PeakNext, PeakPrevious, Remove, JumpToBack, etc...
I would call it PeekNext, PeekPrevious, ...
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-d
2009/10/25 Paul Ishenin :
>
> To use it in the for-in loop you need to add a function MoveNext: Boolean
> (you can choose any other name but you need to mark it using 'enumerator
> MoveMext' modifier) and property Current: TObject (you can choose any other
> name but you need to mark it using 'enum
On Sun, Oct 25, 2009 at 16:49, Paul Ishenin wrote:
>> When I use
>> iterators, I would like to have the ability to use Current, HasNext,
>> HasPrevious, PeakNext, PeakPrevious, Reset, JumpToBack, pass a filter
>> to GetIterator... etc.
>
> I don't argue but how do you think to use HasPrevious, Pea
2009/10/25 Paul Ishenin :
>
> I don't argue but how do you think to use HasPrevious, PeakNext,
> PeakPrevios, Reset, JumpToBack in the for-in loop? Can you suggest a syntax?
I did not expect for-in loop to support all the methods I require (or
use), hence the reason I ask, and why I still would li
Graeme Geldenhuys wrote:
Also, I referred to them in my implementation as Iterators - as per
the Iterator design pattern. How does Enumerator differ from Iterator?
I have looked at you interfaces. They are needs to be changed a bit to
use then in the for-in loop. For example:
ITBIterator =
Graeme Geldenhuys wrote:
Just to recap... What exactly does the function GetEnumerator return?
Specifically for list type classes. Also what interface would that
enumerator support?
Valid return for now is object or class instance. I did not implement
interface support yet. But delphi has the
2009/10/24 Paul Ishenin :
> Enumerator can be found for type using:
>
> 1. GetEnumerator method to the class/object (delphi way). For example:
>
> type
> TSomeClass = class
> public
> function GetEnumerator: TSomeEnumerator;
> end;
Just to recap... What exactly does the function GetEnumerato
Paul Ishenin wrote:
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
At the moment implementation is almost complete and it is possible to
test and review it (although many checks still needs to be added). It
unites 2 approaches: delphi -
On Thu, 22 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
Don't forget the remark by Sergei Gorelkin, that in fact a single
call could be enough.
In fact a single call could not be compatible with delphi solution.
That is so, but none of what is discussed is compatible with Delp
Michael Van Canneyt wrote:
Don't forget the remark by Sergei Gorelkin, that in fact a single
call could be enough.
In fact a single call could not be compatible with delphi solution.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@li
On Thu, 22 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
Hm. I like this direction of thinking, yes...
Hm. I like that after 100 mails of 'yes, I like them', 'no, I don't like
them' we finnaly moved to the initial idea of the tread - design and
implementation discussion :)
Sergei Gorelkin wrote:
> 2) What existing solutions already exist and can be used
... maybe not meaning "using the implementation code", but just
"providing the same syntax".
( I do know that I might be bashed for this. Anyway: )
I think it's always worth to take a look at Prism. Same of co
Michael Van Canneyt wrote:
Hm. I like this direction of thinking, yes...
Hm. I like that after 100 mails of 'yes, I like them', 'no, I don't like
them' we finnaly moved to the initial idea of the tread - design and
implementation discussion :)
What about
function StepNext: Boolean; it
Paul Ishenin pisze:
Marc Weustink wrote:
I can see a use for using iterators in a for loop, however they
should be declared with some keyword.
Something like
type
TListIterator = iterator(TList, init_func, next_func, check_func)
function init_func: Boolean;
function next_func:
Michael Van Canneyt schrieb:
> My only worry now is to make sure that if they are implemented, that we
> make the design as clean as possible: e.g. No hardcoded dependencies on
> class or
> interface names.
>
Afaik Delphi's implementation only depends on the guid: it's the same as
interface ref.
Micha Nelissen pisze:
Michael Van Canneyt wrote:
I see little gain in changing
while Something(f) do
F.Somethingelse
This is not quite equal, it's more like:
Start(f);
while not Last(f) do
F.DoWork;
In your case, the function 'Something' must know about a generic F.
why not
f.start
Alexander Klenin wrote:
On Thu, Oct 22, 2009 at 02:07, Sergei Gorelkin wrote:
As I tried to say earlier, having distinct StepNext() and Current()
functions is somewhat redundant, except the purpose of Delphi compatibility.
Rationale: the for..in loop manages the iterator object itself, and does
On Thu, Oct 22, 2009 at 02:07, Sergei Gorelkin wrote:
> As I tried to say earlier, having distinct StepNext() and Current()
> functions is somewhat redundant, except the purpose of Delphi compatibility.
> Rationale: the for..in loop manages the iterator object itself, and does not
> allow user cod
On Wed, 21 Oct 2009, Sergei Gorelkin wrote:
Michael Van Canneyt wrote:
Hm. I like this direction of thinking, yes...
What about
function StepNext: Boolean; iterator 'movenext';
property TheCurrentValue: Integer; iterator 'current';
or better yet, because it is more strict:
functio
Michael Van Canneyt wrote:
Hm. I like this direction of thinking, yes...
What about
function StepNext: Boolean; iterator 'movenext';
property TheCurrentValue: Integer; iterator 'current';
or better yet, because it is more strict:
function StepNext: Boolean; iterator nextvalue;
prope
On Thu, 22 Oct 2009, Alexander Klenin wrote:
On Thu, Oct 22, 2009 at 01:44, Michael Van Canneyt
wrote:
What about
function StepNext: Boolean; iterator 'movenext';
property TheCurrentValue: Integer; iterator 'current';
You beat me by two minutes ;-)
function StepNext: Boolean; iterato
Paul Ishenin wrote:
Michael Van Canneyt wrote:
My only worry now is to make sure that if they are implemented, that
we make the design as clean as possible: e.g. No hardcoded
dependencies on class or
interface names.
We need to count the pros and contras first regards hardcoded names and
mayb
On Thu, Oct 22, 2009 at 01:44, Michael Van Canneyt
wrote:
> What about
>
> function StepNext: Boolean; iterator 'movenext';
> property TheCurrentValue: Integer; iterator 'current';
You beat me by two minutes ;-)
> function StepNext: Boolean; iterator nextvalue;
> property TheCurrentValue: In
On Thu, Oct 22, 2009 at 01:15, Michael Van Canneyt
wrote:
>> On Tue, Oct 20, 2009 at 20:25, Alexander Klenin wrote:
>>> This is because the while you provided is not equivalent to the for loop
>>> above.
>>> The correct translation would be:
>>> var
>>> it: TSomethingIterator;
>>> ...
>>> it :=
On Wed, 21 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
My only worry now is to make sure that if they are implemented, that we
make the design as clean as possible: e.g. No hardcoded dependencies on
class or
interface names.
We need to count the pros and contras first regards h
Michael Van Canneyt wrote:
My only worry now is to make sure that if they are implemented, that
we make the design as clean as possible: e.g. No hardcoded
dependencies on class or
interface names.
We need to count the pros and contras first regards hardcoded names and
maybe 'hard coded' code.
In our previous episode, Michael Van Canneyt said:
> >> finally
> >>it.Free;
> >> end;
> >>
> >> Now, that is quite e few keystrokes to save, not to mention that
> >> if item value is used more than once in the loop, SomeClass.NextValue must
> >> be
> >> stored in a variable, further bloatin
On Thu, 22 Oct 2009, Alexander Klenin wrote:
I understand what this thread is very long and hard to follow.
However, could you please at least read direct the answers to your mails:
On Tue, Oct 20, 2009 at 20:25, Alexander Klenin wrote:
On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt
wr
On 21 Oct 2009, at 14:55, Marco van de Voort wrote:
That goes for the language feature maybe. The point is to make it
worthwhile, and used, it has to be integrated into everything.
Which, as
that would introduce Delphi incompatibilities probably won't.
Just like generics that still consist
On Thu, Oct 22, 2009 at 00:26, Michael Van Canneyt
wrote:
>> I beg to disagree.This is completely backwards -- like saying that "while"
>> loop is an
>> ugly hack to save some typing of "goto" operators.
>> Iterators and foreach loops are very important tools of structured coding.
>> The fact tha
Michael Van Canneyt wrote:
This is all just nitpicking. Iterators as a language construct are a
very ugly
hack to save some typing, no matter how you turn it. Nice maybe for
languages with dynamic typing and so on, but really not on it's place
in Pascal.
Ok. There is not a problem to make this
Michael Van Canneyt wrote:
I see little gain in changing
while Something(f) do
F.Somethingelse
This is not quite equal, it's more like:
Start(f);
while not Last(f) do
F.DoWork;
In your case, the function 'Something' must know about a generic F.
There are also recursive state problem
On Wed, 21 Oct 2009, Alexander Klenin wrote:
On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt
wrote:
This is all just nitpicking. Iterators as a language construct are a very ugly
hack to save some typing, no matter how you turn it. Nice maybe for
languages with dynamic typing and so on,
Alexander Klenin пишет:
On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt
wrote:
This is all just nitpicking. Iterators as a language construct are a very ugly
hack to save some typing, no matter how you turn it. Nice maybe for
languages with dynamic typing and so on, but really not on it's p
In our previous episode, Jonas Maebe said:
>
> > I've a bit doubts, even aside from any direct opinion on the feature
> > itself,
> > to add functionality to emulate certain features from other
> > language's very
> > extensive libraries (like Java/.NET/Boost), since the development of
> > t
On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt
wrote:
> This is all just nitpicking. Iterators as a language construct are a very ugly
> hack to save some typing, no matter how you turn it. Nice maybe for
> languages with dynamic typing and so on, but really not on it's place in
> Pascal.
I
On 21 Oct 2009, at 14:23, Marco van de Voort wrote:
I've a bit doubts, even aside from any direct opinion on the feature
itself,
to add functionality to emulate certain features from other
language's very
extensive libraries (like Java/.NET/Boost), since the development of
the last
very m
In our previous episode, Michael Van Canneyt said:
> >
> > and then tag methods as so? I think though, that the original suggestion
> > would work if very well documented or allowing for additional tags somehow?
> >
> > MyIterator = Iterator(TSomeResultType, Func1::Next, Func2::Prior);
>
> Nono,
On Wed, 21 Oct 2009, Micha Nelissen wrote:
Michael Van Canneyt wrote:
On Wed, 21 Oct 2009, Micha Nelissen wrote:
So the place in this list determines its function?
Yes. Just like in an operator...
Hmm that's not comparable, for operators it's much more intuitive what to
expect as the co
Michael Van Canneyt wrote:
On Wed, 21 Oct 2009, Micha Nelissen wrote:
So the place in this list determines its function?
Yes. Just like in an operator...
Hmm that's not comparable, for operators it's much more intuitive what
to expect as the context is forced, Result := ;
Micha
On Wed, 21 Oct 2009, Matt Emson wrote:
Micha Nelissen wrote:
Michael Van Canneyt wrote:
Because with something like
Type
MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3);
So the place in this list determines its function?
The syntax is nice and simple, but I would have to agre
On Wed, 21 Oct 2009, Micha Nelissen wrote:
Michael Van Canneyt wrote:
Because with something like
Type
MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3);
So the place in this list determines its function?
Yes. Just like in an operator...
Michael.
___
Micha Nelissen wrote:
Michael Van Canneyt wrote:
Because with something like
Type
MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3);
So the place in this list determines its function?
The syntax is nice and simple, but I would have to agree. Maybe a two
step would be better? Like
Michael Van Canneyt wrote:
Because with something like
Type
MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3);
So the place in this list determines its function?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.
On Wed, 21 Oct 2009, Micha Nelissen wrote:
Michael Van Canneyt wrote:
Ideally, the compiler has no knowledge at all of specific classes, and a
new keyword such as Iterator (or whatever) helps in ensuring that the
compiler
is not contaminated with knowledge of specific classes or methods.
Michael Van Canneyt wrote:
Ideally, the compiler has no knowledge at all of specific classes, and a
new keyword such as Iterator (or whatever) helps in ensuring that the compiler
is not contaminated with knowledge of specific classes or methods.
I'm not sure how things are helped by "slapping"
Michael Van Canneyt wrote:
> Ideally, the compiler has no knowledge at all of specific classes, and a
> new
> keyword such as Iterator (or whatever) helps in ensuring that the compiler
> is not contaminated with knowledge of specific classes or methods.
That is a very conservative (but of course v
Vinzent Höfler wrote:
Von: Micha Nelissen
That's why I suggested the use of 'const functions' in other message in
this thread.
Yes, I read that later on. Is that implemented in FPC?
I don't think so; but I think it would be a useful part of the iterator
proposal. The iterator case really
On Wed, 21 Oct 2009, Paul Ishenin wrote:
Sergei Gorelkin wrote:
The question is, what advantage all this specific syntax could give over
simple searching the methods by name?
Some people need less compiler magic, some does not care. New directive can
reduce the magic level :)
Btw, we us
Paul Ishenin wrote:
Marco van de Voort wrote:
btw the earlier discussions about D2005+ functionality are archived at:
http://www.stack.nl/~marcov/delphilater.txt
I wanted to use this for an article, so the log are sligtly processed
and
annotated.
There is no much threre regards 'for-in'. I
Sergei Gorelkin wrote:
The question is, what advantage all this specific syntax could give over
simple searching the methods by name?
Some people need less compiler magic, some does not care. New directive
can reduce the magic level :)
Btw, we use similar compiler magic every day. Just thin
Paul Ishenin wrote:
Sergei Gorelkin wrote:
Probably yes. A possibility to use any type which has certain
methods/operators instead looks attractive, but I'm afraid it would be
hard to fit that into existing compiler model.
Sorry, what is TIterator? Is this like to the previosly suggested
TI
Marco van de Voort wrote:
btw the earlier discussions about D2005+ functionality are archived at:
http://www.stack.nl/~marcov/delphilater.txt
I wanted to use this for an article, so the log are sligtly processed and
annotated.
There is no much threre regards 'for-in'. I would like if you/some
Sergei Gorelkin wrote:
Probably yes. A possibility to use any type which has certain
methods/operators instead looks attractive, but I'm afraid it would be
hard to fit that into existing compiler model.
Sorry, what is TIterator? Is this like to the previosly suggested
TIterator = interator(,
Vinzent Höfler пишет:
Sergei Gorelkin :
4) The syntax 'for element in list using TListIterator' is kind of
redundant. I'd suggest:
for element in list.GetForwardIterator do ..., or even
for element in list.GetSubItems(arguments) do ...
Wat's the return type of those functions? TIterato
Sergei Gorelkin :
> 4) The syntax 'for element in list using TListIterator' is kind of
> redundant. I'd suggest:
>for element in list.GetForwardIterator do ..., or even
>for element in list.GetSubItems(arguments) do ...
Wat's the return type of those functions? TIterator?
Vinzent.
--
Original-Nachricht
> Datum: Tue, 20 Oct 2009 13:38:40 +0200
> Von: Micha Nelissen
> An: FPC developers\' list
> Betreff: Re: [fpc-devel] New feature discussion: for-in loop
> Vinzent Höfler wrote:
> > Marc Weustink :
> >> loop you are not
Paul Ishenin пишет:
Marc Weustink wrote:
I can see a use for using iterators in a for loop, however they should
be declared with some keyword.
Something like
type
TListIterator = iterator(TList, init_func, next_func, check_func)
function init_func: Boolean;
function next_func:
Martin wrote:
"using" seems far better than a "fixed name GetIterator procedure".
IMHO the other option is to implement the feature for ase types (e.g.
enum, array, maybe string) and allow operator overriding for all other
types.
Then you can specify an enum operator for classes, or even for
Marc Weustink wrote:
I can see a use for using iterators in a for loop, however they should
be declared with some keyword.
Something like
type
TListIterator = iterator(TList, init_func, next_func, check_func)
function init_func: Boolean;
function next_func:
function check_func:
Marc Weustink wrote:
It is bad enough that the second point is already so for interfaces
and even TObject, (a very serious design flaw by Borland) but
extending this even further to include actual language features such
as the for loop is 2 bridges too far
as far as I'm concerned.
Especial
Vinzent Höfler wrote:
Marc Weustink :
loop you are not allowed to modify the loop variable. In this case I can
imagine its not allowed to modify the list.
But how's the compiler supposed to know which method modifies MyList and which one does not?
That's why I suggested the use of 'const fu
Graeme Geldenhuys wrote:
> RemObjects are now in control of Delphi Prism.
No wonder, as they created it :)
I understand that Codegear or Embarcadero pay(ed) them for the license
to sell it.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepasca
On 20/10/2009, Michael Schnell wrote:
>
> They do sell it,
As a curtsey because they gave up on Delphi.NET.
RemObjects are now in control of Delphi Prism.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.
Graeme Geldenhuys wrote:
> In all respects, Delphi Prism is not a Embarcadero product - except
> for the slapped on "Delphi" prefix, Embarcadero has nothing to do with
> Delphi Prism.
They do sell it, so I suppose if they plan language extension (like
iterators) for the native Delphi flavor, they
Marc Weustink :
> Graeme Geldenhuys wrote:
>
> > Another flaw in the for-in concept...
> >
> > What will this do:
> >
> > for y in MyList do
> > begin
> > if y = XXX then
> > MyList.Add(YYY);
> > if y = ZZZ then
> > MyList.Insert(1, AAA);
> > end;
> >
[...]
>
> This
On 20/10/2009, Paul Ishenin wrote:
>
> I don't like non-constructive criticism. If you don't like something please
> be ready to suggest something instead. And in this case something what can
By no means to I suggest that my code should be the final product, but
here I am attaching what I wrote
In our previous episode, Paul Ishenin said:
> Yes, I see this very bad too. That's why this discussion is started. But
> what can be suggested instead?
Does there need something to be suggested per se?
What do you think of the DECAL solution ? It's ackward, but that is because
it is pre-generic
Graeme Geldenhuys :
> Well, with for-in you can only loop through a list is a specific order
> and direction. You can't peak forward, you can't move back, you can't
> filter returned content.
At least you know it will terminate. That always was a guaranteed property of
the for-loop. With being a
On Tue, Oct 20, 2009 at 20:29, Graeme Geldenhuys
wrote:
> On 20/10/2009, Alexander Klenin wrote:
>> Hm. I can not see where lookahead aka peeking
>> is required in using any of the enumerators you mention.
>> UTF8String enumerator is even among the samples on the wiki page.
>>
>
> I just comple
On Tue, 20 Oct 2009, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
Secondly:
You promote a certain class/interface to a language feature. The
compiler then depends on the presence of a certain class with some
'known' methods in the RTL.
The whole interface ref. counting depends on
On 20/10/2009, Alexander Klenin wrote:
>
> Hm. I can not see where lookahead aka peeking
> is required in using any of the enumerators you mention.
> UTF8String enumerator is even among the samples on the wiki page.
>
I just completed a parser for a custom RichText component I wrote for
fpGUI T
On Tue, Oct 20, 2009 at 20:23, Florian Klaempfl wrote:
> Michael Van Canneyt schrieb:
> My opinion about the for-in loop:
> - I won't implement it
> - if somebody else implements it in a delphi compatible manner: fine
> - if somebody else implements it in a delphi compatible manner solving
> the
On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt
wrote:
> But I really don't see the advantage of being able to type
>
> For F in Someclass.Iterator do
> F.Something
>
> over
>
> While SomeClass.HaveValue do
> SomeClasss.NextValue.Something;
>
> It's not clearer, at most it saves you a c
Michael Van Canneyt schrieb:
>
> Secondly:
> You promote a certain class/interface to a language feature. The
> compiler then depends on the presence of a certain class with some
> 'known' methods in the RTL.
>
The whole interface ref. counting depends on that as well as e.g. the
"as" operator.
On Tue, 20 Oct 2009, Alexander Klenin wrote:
On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt
wrote:
You don't know this with an iterator since you depend on the implementation
of the iterator. The loop could loop forever then...
Just as it can when using iterators explicitly. No differe
On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt
wrote:
> You don't know this with an iterator since you depend on the implementation
> of the iterator. The loop could loop forever then...
Just as it can when using iterators explicitly. No difference here.
> Secondly:
> You promote a certain c
On Tue, 20 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
And what is so special in the class type?
First:
For a for loop, you are guaranteed that the loop logic behaves correctly.
A loop is equivalent to the following:
I:=StartValue;
E:=EndValue;
While I<=EndValue do
begin
Michael Van Canneyt wrote:
On Tue, 20 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
At least one of the reasons we never did implement for-in is the
absolutely
horrible and totally wrong idea to use classes/interfaces for this,
to which
I seriously objected.
Reading this I con
Michael Van Canneyt wrote:
And you cannot change I manually during the loop.
You don't know this with an iterator since you depend on the implementation
of the iterator. The loop could loop forever then...
Maybe the iterator function should be a "const" function. A const
function is not allow
On Tue, Oct 20, 2009 at 19:40, Graeme Geldenhuys
wrote:
> // for basic type we will call only the apropriate function
> procedure TraverseString(S: String);
> var
> C: Char;
> begin
> for C in S using GetReverseStringEnumerator(S) do
> DoSomething(C);
> end;
> Now your for-in syntax changes b
Michael Van Canneyt wrote:
And what is so special in the class type?
First:
For a for loop, you are guaranteed that the loop logic behaves correctly.
A loop is equivalent to the following:
I:=StartValue;
E:=EndValue;
While I<=EndValue do
begin
// loop stuff
Inc(I);
end;
And you canno
2009/10/20 Alexander Klenin :
>> I just read the docs in the lazarus wiki. The problems/limitations
>> still hold true. For-in only goes in ONE direction
>
> Hm, did you read the about reverseEnumerators and various irders of
> tree traversals?
---
// for basic type we will call on
On Tue, 20 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
At least one of the reasons we never did implement for-in is the absolutely
horrible and totally wrong idea to use classes/interfaces for this, to
which
I seriously objected.
Reading this I conclude you are against 'for-
On Tue, Oct 20, 2009 at 19:22, Graeme Geldenhuys
wrote:
> 2009/10/20 Alexander Klenin :
>>
>> Well, I suggest you to read at least the link provided in the original post,
>> and maybe also some documention about Delphi/C# enumerators.
>
>
> I just read the docs in the lazarus wiki. The problems/li
Graeme Geldenhuys wrote:
2009/10/20 Alexander Klenin :
for-in is just a syntax sugar plus standard interface for the cost common usage
of iterators. So they are not mutually exclusive at all.
Another flaw in the for-in concept...
What will this do:
for y in MyList do
begin
if y = X
2009/10/20 Michael Schnell :
>
> Re .NET: Delphi Prism does have iterators.
>
> ( http://prismwiki.codegear.com/en/Iterators )
In all respects, Delphi Prism is not a Embarcadero product - except
for the slapped on "Delphi" prefix, Embarcadero has nothing to do with
Delphi Prism.
But yes I know i
1 - 100 of 111 matches
Mail list logo
