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 Sun, Nov 1, 2009 at 17:49, Paul Ishenin webpi...@mail.ru 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
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 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
e.g.) and
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 guess
Micha Nelissen mi...@neli.hopto.org:
Vinzent Höfler wrote:
Von: Micha Nelissen mi...@neli.hopto.org
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
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
2009/10/25 Paul Ishenin webpi...@mail.ru:
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
On Sun, Oct 25, 2009 at 16:49, Paul Ishenin webpi...@mail.ru 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
2009/10/25 Paul Ishenin webpi...@mail.ru:
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
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
On 25/10/2009, Alexander Klenin kle...@gmail.com 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
On 25/10/2009, Vincent Snijders vsnijd...@vodafonevast.nl 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 Sun, Oct 25, 2009 at 20:05, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
On 25/10/2009, Alexander Klenin kle...@gmail.com 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
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
On 25/10/2009, Paul Ishenin webpi...@mail.ru 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
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 -
2009/10/24 Paul Ishenin webpi...@mail.ru:
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
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
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 again for this. Anyway: )
I think it's always worth to take a look at Prism. Same of
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 :)
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 -
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
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
Vinzent Höfler wrote:
Von: Micha Nelissen mi...@neli.hopto.org
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
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
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
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:
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
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
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.
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
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 := expr op expr;
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
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, A::B is
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
On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt
mich...@freepascal.org 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
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
the last
Alexander Klenin пишет:
On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt
mich...@freepascal.org 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,
On Wed, 21 Oct 2009, Alexander Klenin wrote:
On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt
mich...@freepascal.org 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
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
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
On Thu, Oct 22, 2009 at 00:26, Michael Van Canneyt
mich...@freepascal.org 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
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, 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 kle...@gmail.com wrote:
On Tue, Oct 20, 2009 at 20:09,
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.
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
On Thu, Oct 22, 2009 at 01:15, Michael Van Canneyt
mich...@freepascal.org wrote:
On Tue, Oct 20, 2009 at 20:25, Alexander Klenin kle...@gmail.com wrote:
This is because the while you provided is not equivalent to the for loop
above.
The correct translation would be:
var
it:
On Thu, Oct 22, 2009 at 01:44, Michael Van Canneyt
mich...@freepascal.org 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
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
On Thu, 22 Oct 2009, Alexander Klenin wrote:
On Thu, Oct 22, 2009 at 01:44, Michael Van Canneyt
mich...@freepascal.org wrote:
What about
function StepNext: Boolean; iterator 'movenext';
property TheCurrentValue: Integer; iterator 'current';
You beat me by two minutes ;-)
function
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;
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:
On Thu, Oct 22, 2009 at 02:07, Sergei Gorelkin sergei_gorel...@mail.ru 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
Alexander Klenin wrote:
On Thu, Oct 22, 2009 at 02:07, Sergei Gorelkin sergei_gorel...@mail.ru 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
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
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.
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 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;
Hello, FPC developers' list.
I think we can close 'sealed/abstract class' page and open another
interesting topc.
It is obvious you are full of energy to discuss new language features.
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
On Tue, 20 Oct 2009, Paul Ishenin wrote:
Hello, FPC developers' list.
I think we can close 'sealed/abstract class' page and open another
interesting topc.
It is obvious you are full of energy to discuss new language features.
The next feature which we should think of is for-in loop:
2009/10/20 Paul Ishenin i...@kmiac.ru:
It is obvious you are full of energy to discuss new language features.
:-)
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
As an alternative to the very limited for-in, I have a better and
more
On Tue, Oct 20, 2009 at 18:57, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
As an alternative to the very limited for-in, I have a better and
more flexible design, using the Iterator design pattern.
for-in is just a syntax sugar plus standard interface for the cost common usage
of
On Tue, 20 Oct 2009, Graeme Geldenhuys wrote:
2009/10/20 Paul Ishenin i...@kmiac.ru:
It is obvious you are full of energy to discuss new language features.
:-)
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
As an alternative
2009/10/20 Alexander Klenin kle...@gmail.com:
As an alternative to the very limited for-in, I have a better and
more flexible design, using the Iterator design pattern.
for-in is just a syntax sugar plus standard interface for the cost common
usage
of iterators. So they are not mutually
2009/10/20 Alexander Klenin kle...@gmail.com:
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 = XXX then
On Tue, Oct 20, 2009 at 19:03, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
2009/10/20 Alexander Klenin kle...@gmail.com:
As an alternative to the very limited for-in, I have a better and
more flexible design, using the Iterator design pattern.
for-in is just a syntax sugar plus standard
Graeme Geldenhuys wrote:
BTW: Java and .NET have such type of iterators on just about every
list component and it's very handy (I can only comment here on Java
implementation because I don't use .NET).
Re .NET: Delphi Prism does have iterators.
( http://prismwiki.codegear.com/en/Iterators
In our previous episode, Paul Ishenin said:
It is obvious you are full of energy to discuss new language features.
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
There you can find:
1. Delphi implementation details
2. Proposed
2009/10/20 Alexander Klenin kle...@gmail.com:
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/limitations
still hold true. For-in only goes in ONE
2009/10/20 Michael Schnell mschn...@lumino.de:
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
Graeme Geldenhuys wrote:
2009/10/20 Alexander Klenin kle...@gmail.com:
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
On Tue, Oct 20, 2009 at 19:22, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
2009/10/20 Alexander Klenin kle...@gmail.com:
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
2009/10/20 Alexander Klenin kle...@gmail.com:
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
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
On Tue, Oct 20, 2009 at 19:40, Graeme Geldenhuys
graemeg.li...@gmail.com 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
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
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
On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt
mich...@freepascal.org 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
On Tue, 20 Oct 2009, Alexander Klenin wrote:
On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt
mich...@freepascal.org 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
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.
My
On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt
mich...@freepascal.org 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
On 20/10/2009, Alexander Klenin kle...@gmail.com 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
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 Tue, Oct 20, 2009 at 20:29, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
On 20/10/2009, Alexander Klenin kle...@gmail.com 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
Graeme Geldenhuys graemeg.li...@gmail.com:
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
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
On 20/10/2009, Paul Ishenin i...@kmiac.ru 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
Marc Weustink marc.weust...@cuperus.nl:
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 is
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 will
On 20/10/2009, Michael Schnell mschn...@lumino.de 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
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 -
Vinzent Höfler wrote:
Marc Weustink marc.weust...@cuperus.nl:
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
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.
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: element type
function
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
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:
Original-Nachricht
Datum: Tue, 20 Oct 2009 13:38:40 +0200
Von: Micha Nelissen mi...@neli.hopto.org
An: FPC developers\' list fpc-devel@lists.freepascal.org
Betreff: Re: [fpc-devel] New feature discussion: for-in loop
Vinzent Höfler wrote:
Marc Weustink marc.weust
Vinzent Höfler пишет:
Sergei Gorelkin sergei_gorel...@mail.ru:
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
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 =
1 - 100 of 104 matches
Mail list logo
