Jamie McCracken wrote:
> Just wandering if any of you are interested in modernising Pascal which
> is looking quite dated when compared to modern languages like Python. I
> note free pascal supports a variety of pascal dialects but none of them
> are particular modern.
I'd suggest Oberon or a sim
On Wed, 23 Feb 2005 13:45:51 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > one less variable to manually declare
>
> Implement something in lazarus that auto-adds the variable to the
> local var section.
It already exists. Example:
i:=0;
Place cursor on i and press Code Comple
> Marco van de Voort wrote:
> > The constructs are not that frequent, so typing is not limited. I do not
> > agree on
> > the "clearer" part also.
> >
> >>From low to high is more clear than IN, since that says nothing about order.
>
>
> Well for..in is not a replacement for the conventional Fo
Marco van de Voort wrote:
My mistake it actually avoids initialising the loop variable rather than
not declaring it:
for i in myarray do
myarray[i] := 0;
as opposed to
for i := low(myarray) to high (myarray) do
myarray[i] := 0;
I think the for..in is much clearer and more compact (it works f
Jamie McCracken wrote:
Marco van de Voort wrote:
2. For Each. Its in Delphi 2005 and every modern language
implements it.
Yeah, and I still wonder why. There is nothing to gain with it.
one less variable to manually declare
Implement something in lazarus that auto-adds the variable to the
l
> My mistake it actually avoids initialising the loop variable rather than
> not declaring it:
>
> for i in myarray do
>myarray[i] := 0;
>
> as opposed to
>
> for i := low(myarray) to high (myarray) do
> myarray[i] := 0;
>
>
> I think the for..in is much clearer and more compact (it w
On 23 feb 2005, at 14:04, Jamie McCracken wrote:
My mistake it actually avoids initialising the loop variable rather
than not declaring it:
for i in myarray do
myarray[i] := 0;
as opposed to
for i := low(myarray) to high (myarray) do
myarray[i] := 0;
I think the for..in is much clearer and m
Marco van de Voort wrote:
2. For Each. Its in Delphi 2005 and every modern language implements it.
Yeah, and I still wonder why. There is nothing to gain with it.
one less variable to manually declare
Implement something in lazarus that auto-adds the variable to the local var
section. No need
Jamie McCracken wrote:
Florian Klaempfl wrote:
So if you look at this, you know why classes aren't ref. counted. And
there is no chance to avoid the code generated for the interface.
Yes that does look very bad but if you passed a pointer to the ref
counted object as the function arguement then
Florian Klaempfl wrote:
So if you look at this, you know why classes aren't ref. counted. And
there is no chance to avoid the code generated for the interface.
Yes that does look very bad but if you passed a pointer to the ref
counted object as the function arguement then you would not get all t
> Marco van de Voort wrote:
>
> >
> >>The best solution I can
> >>think for this is to reference count non-component classes. This should
> >>be safe for TObjects but obviously not for Tcomponent descendants (cf
> >>circular reference problem) so a protected variable could be added to
> >>TOb
Jamie McCracken wrote:
Marco van de Voort wrote:
The best solution I can think for this is to reference count
non-component classes. This should be safe for TObjects but obviously
not for Tcomponent descendants (cf circular reference problem) so a
protected variable could be added to TObject to
Marco van de Voort wrote:
The best solution I can
think for this is to reference count non-component classes. This should
be safe for TObjects but obviously not for Tcomponent descendants (cf
circular reference problem) so a protected variable could be added to
TObject to specify whether to re
13 matches
Mail list logo
