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
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
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
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"
Jeff Wormsley wrote:
> Wow, talk about unreadable code...
>
In fact I did not ever try to understand this. I just happened to know
about Lambda in Prism and wanted to let the forum share that.
> I'm all for saving typing, but not at the expense of readability.
Agreed.
> This
> reminds me of
Hi,
Just subscribed, testing system.
Regards,
Nino
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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.
fpc...@silvermono.co.za wrote:
Hi,
Just subscribed, testing system.
Welcome
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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.
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 agre
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, 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
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 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
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
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
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
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,
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
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
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
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 wrote:
On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt
wr
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
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 h
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 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
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, 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
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 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
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
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 Wed, 2009-10-21 at 15:54 +0200, Jonas Maebe wrote:
> On 21 Oct 2009, at 14:55, Marco van de Voort wrote:
>
> Generics still don't work 100%,
>
>
> Jonas
>
In what way is Generics not 100%?
Dave Copeland.
___
fpc-devel maillist - fpc-devel@
On Thu, Oct 22, 2009 at 04:08, David B Copeland
wrote:
> In what way is Generics not 100%?
>
> Dave Copeland.
For me at least, the gravest problem is a lack of function-level generics.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.
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
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:
Jeff Wormsley pisze:
Michael Schnell wrote:
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
Wow, talk about unreadable code...
why all vote about something, that wasn't proposed ?
--
Darek
___
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
43 matches
Mail list logo
