Hello everybody,
I would like to propose an enhanced replacement for the special assignment
operators += -= *= and /= :
More pascal-like would be constructs of the form "operator :=" such as
a + := 1;
a div := 3;
a or := b;
a xor := 3;
a << := 1;
Together with my prior proposal of mult
Hello Florian!
>> I would like to propose an enhanced replacement for the special assignment
>> operators += -= *= and /= :
>> More pascal-like would be constructs of the form "operator :=" such as
>> a + := 1;
>> a div := 3;
>> a or := b;
>> a xor := 3;
>> a << := 1;
>> Together with my prior p
Hello all!
It seems like I have hit a very hot spot with my proposal - they must be
something worth...
Let me recapitulate and once more comment on this.
My proposal is to replace the operators "op=" by one operator "op" and a
following ":=".
This can be further enhanced to work together with m
Am 05.08.2010 22:19, schrieb _-jan...@web.de:
> Hello everybody,
>
> I would like to propose an enhanced replacement for the special assignment
> operators += -= *= and /= :
> More pascal-like would be constructs of the form "operator :=" such as
> a + := 1;
> a div := 3;
> a or := b;
> a
I guess that the problem which you want to solve is "having to type
too much". If that is the case, you should rather work on improving
code completion in Lazarus or whichever IDE you use. Then you could
type something like += and Ctrl+Alt+C and it would expand to the
natural Pascal version. Or whi
On Thu, 5 Aug 2010, Felipe Monteiro de Carvalho wrote:
I guess that the problem which you want to solve is "having to type
too much". If that is the case, you should rather work on improving
code completion in Lazarus or whichever IDE you use. Then you could
type something like += and Ctrl+Alt
On Fri, Aug 6, 2010 at 07:23, Florian Klämpfl wrote:
> Am 05.08.2010 22:19, schrieb _-jan...@web.de:
>> Hello everybody,
>>
>> I would like to propose an enhanced replacement for the special assignment
>> operators += -= *= and /= :
>> More pascal-like would be constructs of the form "operator :=
On Fri, Aug 6, 2010 at 08:29, Michael Van Canneyt
wrote:
> Pascal as it is, is a very readable language as opposed to C. Proposals such
> as this diminish the readability.
FWIW, while migrating to FPC/newer Delphi,
I specifically replace all usage of Inc/Dec and Include/Exclude in my
Pascal progr
In our previous episode, Alexander Klenin said:
> > as this diminish the readability.
>
> FWIW, while migrating to FPC/newer Delphi,
> I specifically replace all usage of Inc/Dec and Include/Exclude in my
> Pascal programs
> by += / -= *to increase readability*.
> And I think it really helps ;-)
On Fri, Aug 6, 2010 at 14:08, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> > as this diminish the readability.
>>
>> FWIW, while migrating to FPC/newer Delphi,
>> I specifically replace all usage of Inc/Dec and Include/Exclude in my
>> Pascal programs
>> by += / -
Alexander Klenin :
> C-like operators reduce the number of required punctuation --
> I always think that the extra punctuation is bad for readability.
Rght. Shrt sntncs r mch sr t rd.
SCNR,
Vnznt.
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservie
Vinzent Höfler wrote:
> Alexander Klenin :
>
>> C-like operators reduce the number of required punctuation --
>> I always think that the extra punctuation is bad for readability.
>
> Rght. Shrt sntncs r mch sr t rd.
>
This is more about
SomeReallyLongVariableNameX += 10;
being nicer to read
On Fri, Aug 6, 2010 at 16:08, "Vinzent Höfler"
wrote:
> Alexander Klenin :
>
>> C-like operators reduce the number of required punctuation --
>> I always think that the extra punctuation is bad for readability.
>
> Rght. Shrt sntncs r mch sr t rd.
(No) ((but) the sentences (without (extra)) paren
Op 2010-08-06 05:05, Alexander Klenin het geskryf:
> I specifically replace all usage of Inc/Dec and Include/Exclude in my
> Pascal programs
> by += / -= *to increase readability*.
> And I think it really helps ;-)
:-) I do the same, and use += and -+ more - simply to save on typing. But
what Jane
-1
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
In our previous episode, Alexander Klenin said:
> >
> > I think they are unreadable,
>
> C-like operators reduce the number of required punctuation --
> I always think that the extra punctuation is bad for readability.
No. Natural languages are also very redundant, and punctuation is not
even 100
On 6 August 2010 06:08, "Vinzent Höfler" wrote:
> Alexander Klenin :
>
>> C-like operators reduce the number of required punctuation --
>> I always think that the extra punctuation is bad for readability.
>
> Rght. Shrt sntncs r mch sr t rd.
Punctuation <> vowels.
On Fri, 6 Aug 2010, Henry Vermaak wrote:
On 6 August 2010 06:08, "Vinzent Höfler" wrote:
Alexander Klenin :
C-like operators reduce the number of required punctuation --
I always think that the extra punctuation is bad for readability.
Rght. Shrt sntncs r mch sr t rd.
Punctuation <> vo
In our previous episode, Michael Van Canneyt said:
>
> Well, let's all communicate binary.
>
> You then have to know only 2 letters: 0 and 1.
> Things can't be made more simple than that.
Within 5 seconds somebody thinks that is too verbose, and applies a RLE
(run length encoding).
On 6 August 2010 09:34, Michael Van Canneyt wrote:
>
> Well, let's all communicate binary.
>
> You then have to know only 2 letters: 0 and 1. Things can't be made more
> simple than that.
What does this have to do with punctuation not being readable?
Also, simplicity <> readability.
Am 05.08.2010 23:09, schrieb _-jan...@web.de:
a<< := 1;
a,b<< := 1;
BTW: I wrote<< by mistake; it should have been shl.
Just as a sidenote: FPC understands "<<" and ">>" as well (they are
completly equal to "shl" and "shr")
Regards,
Sven
__
On Fri, 6 Aug 2010, Henry Vermaak wrote:
On 6 August 2010 09:34, Michael Van Canneyt wrote:
Well, let's all communicate binary.
You then have to know only 2 letters: 0 and 1. Things can't be made more
simple than that.
What does this have to do with punctuation not being readable?
Also,
Op 2010-08-06 10:54, Michael Van Canneyt het geskryf:
> Once again, a perfect illustration: I should never attempt humor on a mailing
> list.
> Any attempts at irony or even sarcasm are totally lost.
Don't you learn from MY mistakes. ;-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platf
On 6 August 2010 09:54, Michael Van Canneyt wrote:
>
>
> On Fri, 6 Aug 2010, Henry Vermaak wrote:
>
>> On 6 August 2010 09:34, Michael Van Canneyt
>> wrote:
>>>
>>> Well, let's all communicate binary.
>>>
>>> You then have to know only 2 letters: 0 and 1. Things can't be made more
>>> simple than
On Fri, Aug 6, 2010 at 10:43 AM, Henry Vermaak wrote:
> What does this have to do with punctuation not being readable?
What do you mean with punctuation? The ; in the end of pascal lines?
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-d
On Fri, Aug 6, 2010 at 17:56, Graeme Geldenhuys wrote:
> Op 2010-08-06 05:05, Alexander Klenin het geskryf:
>> I specifically replace all usage of Inc/Dec and Include/Exclude in my
>> Pascal programs
>> by += / -= *to increase readability*.
>> And I think it really helps ;-)
>
> :-) I do the same,
On Fri, Aug 6, 2010 at 19:06, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> C-like operators reduce the number of required punctuation --
>> I always think that the extra punctuation is bad for readability.
[..]
> punctuation is not even 100% required to understand
In our previous episode, Alexander Klenin said:
> >> I always think that the extra punctuation is bad for readability.
> [..]
> > punctuation is not even 100% required to understand natural language.
>
> Correct. That is why reducing it to a required minimum is a good thing.
It is not, for the sa
Alexander Klenin wrote:
inc and dec work fine as far as I know for over a decade.
Hm, just re-checked -- no, they do not.
OK on scalars I believe but not on object properties.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employe
On 06/08/2010 11:31, Marco van de Voort wrote:
In our previous episode, Alexander Klenin said:
punctuation is not even 100% required to understand natural language.
Correct. That is why reducing it to a required minimum is a good thing.
It is not, for the same reason all redu
On 06/08/2010 06:19, Michalis Kamburelis wrote:
This is more about
SomeReallyLongVariableNameX += 10;
being nicer to read than
SomeReallyLongVariableNameX := SomeReallyLongVariableNameX + 10;
You don't have to spend time realizing that it's the same variable (not
e.g. SomeReallyLongVar
Martin wrote:
And, since I also refuse to learn from the faults of others, some
sarcasm in the end:
begin end is awfull amount of typing => can we replace it with something
shorter? "{" is unfortunately taken, but why need an actual char => just
identify a block, by indenting each line of the blo
Op 2010-08-06 13:36, Paulo Costa het geskryf:
>
> SomeReallyLongVariableNameX += SomeReallyLongVariableNameY - 1;
>
> is too much similar (visually) to
>
> SomeReallyLongVariableNameX := SomeReallyLongVariableNameY - 1;
Umm, hello... those two statements are not the same. To make the
On 6 August 2010 12:57, Graeme Geldenhuys wrote:
> Op 2010-08-06 13:36, Paulo Costa het geskryf:
>>
>> SomeReallyLongVariableNameX += SomeReallyLongVariableNameY - 1;
>>
>> is too much similar (visually) to
>>
>> SomeReallyLongVariableNameX := SomeReallyLongVariableNameY - 1;
>
>
> Umm,
Op 2010-08-06 14:01, Henry Vermaak het geskryf:
>
> He said it's _visually_ similar.
Ah, then I misunderstood. Apologies.
On a side note:
Maybe it's just me, but I clearly spot the difference between a := and +=
symbol. I guess it's years of experience looking at code, which counts in
my favour
On 6 August 2010 13:04, Graeme Geldenhuys wrote:
> Op 2010-08-06 14:01, Henry Vermaak het geskryf:
>>
>> He said it's _visually_ similar.
>
> Ah, then I misunderstood. Apologies.
>
>
> On a side note:
> Maybe it's just me, but I clearly spot the difference between a := and +=
> symbol. I guess it'
Op 2010-08-06 14:11, Henry Vermaak het geskryf:
> I have more of a problem with commas and full stops on
> some fonts. I also hate it when people don't put spaces between
> operators and text, I find that really unreadable.
+1[...and don't the FPC core team love to code like that. :-( ...]
I
On Fri, Aug 6, 2010 at 21:31, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
As for multiplication, floating-point and overloaded cases,
they are simply required since Inc and Dec do not work at all.
>>> inc and dec work fine as far as I know for over a decad
On 06/08/2010 14:53, Alexander Klenin wrote:
Logical ones are actually less important for me,
but mod= and especially div= are rather useful.
Last time I wished a had div= was just a week ago.
I could see that in a language where div was some symbol (like % or :)
but with a word?
Anyway, co
On Fri, Aug 6, 2010 at 22:17, Martin wrote:
> -
> Readability is not equal to the sortest form of expressing something, in
> fact, the shortest form often lacks readability => hence many people dislike
> reg expression (which infact can be wonderfully short.
> in perl:
> $a := 11;
> if
On Sat, Aug 7, 2010 at 01:12, Martin wrote:
> On 06/08/2010 14:53, Alexander Klenin wrote:
>>
>> Logical ones are actually less important for me,
>> but mod= and especially div= are rather useful.
>> Last time I wished a had div= was just a week ago.
>
> I could see that in a language where div w
On 06/08/2010 15:23, Alexander Klenin wrote:
On Sat, Aug 7, 2010 at 01:12, Martin wrote:
On 06/08/2010 14:53, Alexander Klenin wrote:
Logical ones are actually less important for me,
but mod= and especially div= are rather useful.
Last time I wished a had div= was just a week ago.
I could
On Sat, Aug 7, 2010 at 01:37, Martin wrote:
> On 06/08/2010 15:23, Alexander Klenin wrote:
>>
>> On Sat, Aug 7, 2010 at 01:12, Martin wrote:
>> What it the difference? I agree that "%" is slightly better notation than
>> "mod",
>> but that is totally insignificant, and since we are stuck with "m
On 06/08/2010 15:45, Alexander Klenin wrote:
On Sat, Aug 7, 2010 at 01:37, Martin wrote:
On 06/08/2010 15:23, Alexander Klenin wrote:
On Sat, Aug 7, 2010 at 01:12, Martinwrote:
What it the difference? I agree that "%" is slightly better notation than
"mod",
but that is totally insignifi
On Sat, Aug 7, 2010 at 01:50, Martin wrote:
> On 06/08/2010 15:45, Alexander Klenin wrote:
>
> I don't have a problem with "a mod b" => only with "a mod= b"
>
> mod is a keyword, it therefore follows the rule (as identifier) that it
> consists of certain chars only (a-z, underscore, digits, but
On 06/08/2010 16:21, Alexander Klenin wrote:
On Sat, Aug 7, 2010 at 01:50, Martin wrote:
On 06/08/2010 15:45, Alexander Klenin wrote:
I don't have a problem with "a mod b" => only with "a mod= b"
mod is a keyword, it therefore follows the rule (as identifier) that it
consists of certain
Michalis Kamburelis schrieb:
C-like operators reduce the number of required punctuation --
I always think that the extra punctuation is bad for readability.
Rght. Shrt sntncs r mch sr t rd.
;-)
This is more about
SomeReallyLongVariableNameX += 10;
being nicer to read than
SomeReallyL
Michalis Kamburelis :
> Vinzent Höfler wrote:
> > Alexander Klenin :
> >
> >> C-like operators reduce the number of required punctuation --
> >> I always think that the extra punctuation is bad for readability.
> >
> > Rght. Shrt sntncs r mch sr t rd.
> >
>
> This is more about
>
> SomeReal
Graeme Geldenhuys :
> Op 2010-08-06 05:05, Alexander Klenin het geskryf:
> > I specifically replace all usage of Inc/Dec and Include/Exclude in my
> > Pascal programs
> > by += / -= *to increase readability*.
> > And I think it really helps ;-)
>
> :-) I do the same, and use += and -+ more - simp
On Sat, Aug 7, 2010 at 03:10, "Vinzent Höfler"
wrote:
>> You don't have to spend time realizing that it's the same variable (not
>> e.g. SomeReallyLongVariableNameY) if you read the 1st form.
>
> But you can mistake the "+=" for a ":=". Replacing one possible reading error
> with another isn't mu
Michael Van Canneyt :
> On Fri, 6 Aug 2010, Henry Vermaak wrote:
>
> > On 6 August 2010 06:08, "Vinzent Höfler"
> wrote:
> >> Alexander Klenin :
> >>
> >>> C-like operators reduce the number of required punctuation --
> >>> I always think that the extra punctuation is bad for readability.
> >>
>
On 2010-08-06 1:23 PM, Alexander Klenin wrote:
Correct.
I agree.
That is why reducing it to a required minimum is a good thing.
I agree with the idea.
But, not with the proposal.
Not the way it is made, anyway.
Why not come up with a small application/utility that caters for the
oppositio
Marc Weustink :
> Martin wrote:
> > And, since I also refuse to learn from the faults of others, some
> > sarcasm in the end:
> > begin end is awfull amount of typing => can we replace it with something
> > shorter? "{" is unfortunately taken, but why need an actual char => just
> > identify a blo
Graeme Geldenhuys :
> Maybe it's just me, but I clearly spot the difference between a := and +=
> symbol. I guess it's years of experience looking at code, which counts in
> my favour. ;-)
Well, I am approaching forty now at high-speed (at least that's what it feels
like) and my eyes aren't gett
On Sat, Aug 7, 2010 at 02:34, Martin wrote:
> On 06/08/2010 16:21, Alexander Klenin wrote:
> It's not about implementation in the fpc parser/compiler, or syntax
> highlighter => you can implement any such thing...
>
> But it's breaking the fundamentals of pascal, to differentiate between
> symbol
On 06/08/2010 17:38, Alexander Klenin wrote:
On Sat, Aug 7, 2010 at 03:10, "Vinzent Höfler"
wrote:
You don't have to spend time realizing that it's the same variable (not
e.g. SomeReallyLongVariableNameY) if you read the 1st form.
But you can mistake the "+=" for a ":=". Replacing one possib
On 06/08/2010 18:29, Alexander Klenin wrote:
On Sat, Aug 7, 2010 at 02:34, Martin wrote:
On 06/08/2010 16:21, Alexander Klenin wrote:
It's not about implementation in the fpc parser/compiler, or syntax
highlighter => you can implement any such thing...
But it's breaking the fundamentals of
On Sat, Aug 7, 2010 at 04:35, Martin wrote:
> On 06/08/2010 17:38, Alexander Klenin wrote:
>> Code bloat/duplication is much more serious.
>> It is usually not just SomeReallyLongVariableNameY, but something like:
>> SomeFunctionReturningObject(param1, param2).PointArrayField[i] +=
>> FunctionRet
Alexander Klenin :
> On Sat, Aug 7, 2010 at 03:10, "Vinzent Höfler"
> >
> > But you can mistake the "+=" for a ":=". Replacing one possible reading
> error with another isn't much of an improvement.
>
> You can also mistake "." for ",", ">=" for "<=", or mix up "<>", "><",
> "<<" and ">>" --
> wh
On Sat, Aug 7, 2010 at 04:59, "Vinzent Höfler"
wrote:
> Alexander Klenin :
>
>> > But you can mistake the "+=" for a ":=". Replacing one possible reading
>> error with another isn't much of an improvement.
>>
>> You can also mistake "." for ",", ">=" for "<=", or mix up "<>", "><",
>> "<<" and ">>
On Sat, Aug 7, 2010 at 04:52, Martin wrote:
>
> "aesthetically dislike " = bad readability => see above...
Not quite. For example I dislike indentation by three spaces, and "begin"s
at the start of line, but both of those do not really impede my code reading.
OTOH, inconsistent indentation and be
In our previous episode, Alexander Klenin said:
> in assignment operator is a good idea ("+:=" vs "+=").
> Unfortunately, it is too late for that.
> Another interesting but unrealistic option is something like
> a :=[+] b;
>
> I can even concede to use a function-like syntax, as long as it is
> co
Alexander Klenin :
> On Sat, Aug 7, 2010 at 04:59, "Vinzent Höfler"
> wrote:
> > Alexander Klenin :
> >
> > Except for the ">=" "<=" the resulting error would not compile in most
> cases. THAT's the difference.
>
> I thought we were talking about reading errors, not writing errors?
If you'd lik
At 11:23 AM 8/6/2010, _-jan...@web.de wrote:
Hello all!
It seems like I have hit a very hot spot with my proposal - they
must be something worth...
Let me recapitulate and once more comment on this.
My proposal is to replace the operators "op=" by one operator "op"
and a following ":=".
This
Alexander Klenin schrieb:
I do think that begin/end is an awful amount of visual clutter,
and that Modula solution is a better one.
"begin" can be omitted in many cases, but "end" is inevitable to denote
the end of any block (except "until"...).
Unfortunately, this change is totally out of
Vinzent Höfler schrieb:
Sometimes I really wonder if the buddies K&R when designing C
actually looked at the keyboard and tried to assign a meaning to each
special character they found there. Obviously, they seem to have
missed "$". Probably this one was either too BASIC or too
"establishment".
Vinzent Höfler schrieb:
Yes, back to the good old times where we typed hex listings out of
badly copied magazines. Programming was so much easier when all was
needed were the characters from 0-9, A-F, space, and newline.[1]
Vinzent.
[1] And a lot of time to find the typo that crashed the comp
On Sat, Aug 7, 2010 at 08:56, "Vinzent Höfler"
wrote:
> Alexander Klenin :
>> Exactly, and so we are back to square one -- you accumulate integers with
>> "Inc",
>> points with "AddPoint", doubles with "FloatInc", write extraneous
>> four-line wrapper for every type and always forget which of
>> M
In our previous episode, Alexander Klenin said:
> >
> > Well, if you do it that way... I'd use overloading and use the same name
> > (or, admitted, even the same operator) for the same concept.
>
> IIRC, overloading is not available in Delphi 7 either.
Delphi4. But IIRC at first they only allowe
On Sat, Aug 7, 2010 at 16:56, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> >
>> > Well, if you do it that way... I'd use overloading and use the same name
>> > (or, admitted, even the same operator) for the same concept.
>>
>> IIRC, overloading is not available i
Am 06.08.2010 05:05, schrieb Alexander Klenin:
> On Fri, Aug 6, 2010 at 08:29, Michael Van Canneyt
> wrote:
>> Pascal as it is, is a very readable language as opposed to C. Proposals such
>> as this diminish the readability.
>
> FWIW, while migrating to FPC/newer Delphi,
> I specifically replace
Alexander Klenin wrote:
Code bloat/duplication is much more serious.
It is usually not just SomeReallyLongVariableNameY, but something like:
SomeFunctionReturningObject(param1, param2).PointArrayField[i] +=
FunctionReturningPointOffset(param);
Try rewriting that without "+=".
Again, we are bac
On 07/08/2010 08:28, Florian Klämpfl wrote:
Nevertheless inc/dec generates better code because fpc is too dump to
convert += / -= into inc/dec etc. :)
Better in which way?
I did a quick test (on a very simple source only) (fpc 2.5.1)
inc(a), a+=1; a:= a + 1; all generate "incl"
inc(a,3); a
Am 07.08.2010 12:04, schrieb Martin:
> On 07/08/2010 08:28, Florian Klämpfl wrote:
>>
>> Nevertheless inc/dec generates better code because fpc is too dump to
>> convert += / -= into inc/dec etc. :)
> Better in which way?
>
> I did a quick test (on a very simple source only) (fpc 2.5.1)
>
> inc(
On Sat, Aug 7, 2010 at 20:54, Marc Weustink wrote:
> Alexander Klenin wrote:
>
>> Code bloat/duplication is much more serious.
>> It is usually not just SomeReallyLongVariableNameY, but something like:
>> SomeFunctionReturningObject(param1, param2).PointArrayField[i] +=
>> FunctionReturningPointOf
Marc Weustink schrieb:
What is wrong with :
MyObj.PointArrayField[i] := MyObj.PointArrayField[i] +
FunctionReturningPointOffset(param)
The need for duplicating a long expression, with chances for typos :-(
DoDi
___
fpc-devel maillist - fpc-dev
Hans-Peter Diettrich wrote:
Marc Weustink schrieb:
What is wrong with :
MyObj.PointArrayField[i] := MyObj.PointArrayField[i] +
FunctionReturningPointOffset(param)
The need for duplicating a long expression, with chances for typos :-(
Choose shorter expressions and/or use ctrl+space
Marc
Marc Weustink schrieb:
What is wrong with :
MyObj.PointArrayField[i] := MyObj.PointArrayField[i] +
FunctionReturningPointOffset(param)
The need for duplicating a long expression, with chances for typos :-(
Choose shorter expressions and/or use ctrl+space
And how do I find out, whether t
On 07/08/2010 16:03, Hans-Peter Diettrich wrote:
Marc Weustink schrieb:
What is wrong with :
MyObj.PointArrayField[i] := MyObj.PointArrayField[i] +
FunctionReturningPointOffset(param)
The need for duplicating a long expression, with chances for typos :-(
Choose shorter expressions and/o
On 2010-08-07 6:17 PM, Martin wrote:
The data in MyObj.PointArrayField belongs to MyObj => so why not tell
MyObj what to do with that data?
First I thought it meant 'therefore', 'hence' or 'thus', but replacing
'=>' in the sentence above did not make much sense.
What is it supposed to mean?
Hans-Peter Diettrich :
> A {$mode Modula} would not break anything - it only would make such
> units hard to read, for people with other language preferences.
And you'd have to write the keywords all UPPERCASE then. Better to use {$mode
Ada} for that. ;)
Vinzent.
--
GRATIS für alle GMX-Mitgl
Alexander Klenin :
> As I already said in this thread, "lazy typing" is a fallacious argument.
> The whole history of high-level programming languages may be summarized
> as "lazy typing advancements".
Surely not. But that's a different matter.
> > What is wrong with :
> >
> > MyObj := SomeFunct
Hans-Peter Diettrich :
> Marc Weustink schrieb:
>
> > What is wrong with :
> >
> > MyObj.PointArrayField[i] := MyObj.PointArrayField[i] +
> > FunctionReturningPointOffset(param)
>
> The need for duplicating a long expression, with chances for typos :-(
So we need Ada's renaming feature?
dec
On 08/06/2010 07:35 PM, Martin wrote:
I tried earlier to use += on a property => and got a compile error.
A property can't be used as a var parameter. You can't do "inc (x.a)".
The "+= procedure" - similar as inc() - needs a kind of var-parameter.
It seem like a nice enhancement to allow fo
Hello Adem,
Friday, August 6, 2010, 6:48:22 PM, you wrote:
A> IOW, write a small/simple utility that converts a given source to/from
A> those shorthand operators to/from their long form.
A> If there was such a thing and if it produced code that compiled to give
A> identical results, I would have
85 matches
Mail list logo
