Re: [fpc-pascal] += property bug?

[Rainer Stratmann]

On Mittwoch, 14. August 2019 14:15:51 CEST Ryan Joseph wrote:
> > On Aug 14, 2019, at 12:33 PM, Rainer Stratmann
> >  wrote:
> > 
> > Didn't you know that Ryan?
> 
> Yes, of course, I use them all the time and it’s why I was defending them
> from their critics (which I still find hard to believe even exist).
> Anyways, they exist and can be disabled using the directive Sven mentioned.
> Everyone wins. :)

Even in your sentences you put (too) much in a small place.
I can hardly understand what you mean.
May by I am not so good in English language.

> Regards,
>   Ryan Joseph
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Sven Barth via fpc-pascal]

Am 15.08.2019 um 00:39 schrieb Jean SUZINEAU:

Le 14/08/2019 à 23:18, Martin a écrit :

inc(CALL_LVL [ LOCAL_CALL ],1)

Yes, "inc" does not work for properties. But neither does +=.


I agree and in the case of a property I think it would be cleaner to 
code an Inc method directly in the class, or eventually in a class 
helper, to write something like:


CALL_LVL [ LOCAL_CALL ].Inc(1)

In case of property, it's likely that you'll even be able to optimize 
the code, trimming some lines of the getter and the setter in you Inc 
method.
Please note that this won't work if CALL_LVL is a property and the 
returned type is a record is the returned value will be a temporary 
variable, thus you'd increase the value of the temp, but not of the one 
stored in the class.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[James Richters]

I agree, I hate the self. And this.  I really don't even understand them... 
I'll keep Freepascal too, which I've been able to do more with than I ever 
imagined possible.

James
>I also think to the worse case, in Java, when you need to type something like 
>a.SetX( a.GetX()+1) ...
>And to Python, where in the code of the methods I need to prefix all accesses 
>to methods and attributes of the object with "self." I have some code self. 
>self. self. everywhere ...
>Variant in Javascript: this. this. this.
>Variant in PHP: $this. $this. $this.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Jean SUZINEAU]

Le 14/08/2019 à 23:18, Martin a écrit :

inc(CALL_LVL [ LOCAL_CALL ],1)

Yes, "inc" does not work for properties. But neither does +=.


I agree and in the case of a property I think it would be cleaner to 
code an Inc method directly in the class, or eventually in a class 
helper, to write something like:


CALL_LVL [ LOCAL_CALL ].Inc(1)

In case of property, it's likely that you'll even be able to optimize 
the code, trimming some lines of the getter and the setter in you Inc 
method.


This said, I like to use += when I code in C++ for Arduino

I also think to the worse case, in Java, when you need to type something 
like a.SetX( a.GetX()+1) ...
And to Python, where in the code of the methods I need to prefix all 
accesses to methods and attributes of the object with "self." I have 
some code self. self. self. everywhere ...

Variant in Javascript: this. this. this.
Variant in PHP: $this. $this. $this.

Yes, I keep my FreePascal   ;-)


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Martin]

On 14/08/2019 23:05, Bernd Oppolzer wrote:


4 characters in your case, but if you have for example:

CALL_LVL [ LOCAL_CALL ] := CALL_LVL [ LOCAL_CALL ] + 1 ;

  inc(CALL_LVL [ LOCAL_CALL ],1)

"inc(,)"  vs "+="
6 vs 2 chars

4 more.

Yes, "inc" does not work for properties. But neither does +=.



and you write instead:

CALL_LVL [ LOCAL_CALL ] += 1;


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Bernd Oppolzer]

Am 14.08.2019 um 17:41 schrieb wkitt...@windstream.net:

On 8/14/19 10:54 AM, Ryan Joseph wrote:
Seriously? why is i := i + 1 better than i += 1 ? just more typing 
for such a
simple operation. All languages I use have adopted this syntax and 
for good

reason.


good reason?? because someone is too lazy to type 4 more characters? 
yes, i'm counting the readability spaces which could easily be left 
out...


/me tightens belt on asbestos britches...




4 characters in your case, but if you have for example:

CALL_LVL [ LOCAL_CALL ] := CALL_LVL [ LOCAL_CALL ] + 1 ;

and you write instead:

CALL_LVL [ LOCAL_CALL ] += 1;

it's more than 4 chars, and it's easier, when it comes to changes,
and and and ...

This is only a simple example; consider arrays with more indexes and
record components and pointer references ...

BTW: the two statements are not equivalent, if the index expression
contains for example a function call with side effects :-)

PL/1 is another language which has been enhanced to support this
notation some years ago.

Kind regards

Bernd

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[James Richters]

We're talking apples and oranges here.. sorry my mistake.   I was referring to 
the defaults in the Text IDE,  fp.cfg, not fpc.cfg.If you delete fp.cfg or 
run the Text IDE (fp.exe) from a directory you never ran it in before, it 
creates new fp.cfg, and fp.ini and the default for those new files it creates 
is to have nothing on except "Allow LABEL and GOTO" and "Allow inline".  All 
other Syntax Switches are turned off including  "C-like operators" by default 
when the text IDE creates a new fp.cfg and fp.ini from scratch.

James

>> No,  the default is for ”C-Like operators” to be disabled in FPC.

>No, Sven is right.
>This is in the default fpc.cfg
># Allow goto, inline, C-operators, C-vars -Sgic

>Of course if you delete that file, then all these are off.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Bart]

On Wed, Aug 14, 2019 at 9:03 PM James Richters
 wrote:

> No,  the default is for ”C-Like operators” to be disabled in FPC.

No, Sven is right.
This is in the default fpc.cfg
# Allow goto, inline, C-operators, C-vars
-Sgic

Of course if you delete that file, then all these are off.

-- 
Bart
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 14, 2019, at 3:15 PM, James Richters  
> wrote:
> 
> I find 
>  viewTransform := TMat4.Identity;
>  viewTransform := viewTransform  * TMat4.Translate(x, y, 1);
>  viewTransform := viewTransform  * TMat4.Scale(scale, scale, 1);
> 
> much more readable.  

then by having both we all win. I never said we shouldn’t both, I’m just 
reacting to the idea that FPC almost didn’t include them because they "aren’t 
desirable".

> 
> But I would just do:
>  viewTransform := TMat4.Identity  * TMat4.Translate(x, y, 1) * 
> TMat4.Scale(scale, scale, 1);
> 
> why bother storing the intermediate results at all?

Maybe that was a bad example but I still like to break up lines. For anyone 
that knows, does the compiler have any fancy optimizations to not store the 
intermediate results?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[James Richters]

I find 
  viewTransform := TMat4.Identity;
  viewTransform := viewTransform  * TMat4.Translate(x, y, 1);
  viewTransform := viewTransform  * TMat4.Scale(scale, scale, 1);

much more readable.  

But I would just do:
  viewTransform := TMat4.Identity  * TMat4.Translate(x, y, 1) * 
TMat4.Scale(scale, scale, 1);

why bother storing the intermediate results at all?

Putting the operator before the = makes you have to go back and look to see 
what the operator is, where having the code in Result := Term * Term;  format 
is more readable because you read it left to right and the operators are in the 
correct order they are actually used.   I admit I am probably biased by looking 
at code without += for 35 years, but I still find it more readable.   I 
completely understand += -= *= and /= I just don't care for it from a 
readability point of view.. and figuring our what some code is doing 2 years 
from now is way more important than getting it to work right now... it's when 
you go back later you want it to be as readable as possible.  I guess I just 
prefer  Variable := Formula;  syntax and the clarity of it.

James 


-Original Message-
From: fpc-pascal  On Behalf Of Ryan 
Joseph
Sent: Wednesday, August 14, 2019 2:58 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] += property bug?



> On Aug 14, 2019, at 2:53 PM, James Richters  
> wrote:
> 
> I have only used  += once;  I normally would not use I:=I+1; or I+=1;   I 
> would use Inc(I);

Here’s an example of why we like c-style operators, i.e. it reduces redundancy 
of the variable name. It’s no surprise that programmesr figured out 
"viewTransform := viewTransform  *” could be compressed and still have the same 
meaning.

  viewTransform := TMat4.Identity;
  viewTransform *= TMat4.Translate(x, y, 1);
  viewTransform *= TMat4.Scale(scale, scale, 1);

or

  viewTransform := TMat4.Identity;
  viewTransform := viewTransform  * TMat4.Translate(x, y, 1);
  viewTransform := viewTransform  * TMat4.Scale(scale, scale, 1);

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[James Richters]

>They already are, but not a modeswitch, but a directive: {$COperators On/Off}. 
>Probably from a time before modeswitches were introduced. 

>It's even per default off. The default fpc.cfg however enables them... 

 

No,  the default is for ”C-Like operators” to be disabled in FPC.  I just 
deleted fp.cfg and ran the text IDE and “Allow LABEL and GOTO” and “Allow 
inline” are the only two compiler options that are on by default with FPC… note 
this it not the Lazarus version of FPC, which has been modified, in fact the 
Lazarus version does not even have the text IDE included with it.  If anything 
perhaps it is a bug of Lazarus to turn it on by default when FPC by itself has 
it off by default.

 

James

 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 14, 2019, at 2:53 PM, James Richters  
> wrote:
> 
> I have only used  += once;  I normally would not use I:=I+1; or I+=1;   I 
> would use Inc(I);

Here’s an example of why we like c-style operators, i.e. it reduces redundancy 
of the variable name. It’s no surprise that programmesr figured out 
"viewTransform := viewTransform  *” could be compressed and still have the same 
meaning.

  viewTransform := TMat4.Identity;
  viewTransform *= TMat4.Translate(x, y, 1);
  viewTransform *= TMat4.Scale(scale, scale, 1);

or

  viewTransform := TMat4.Identity;
  viewTransform := viewTransform  * TMat4.Translate(x, y, 1);
  viewTransform := viewTransform  * TMat4.Scale(scale, scale, 1);

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[James Richters]

I have only used  += once;  I normally would not use I:=I+1; or I+=1;   I would 
use Inc(I);

FPC does not compile I+=1; by default,  you have to go into compiler options 
and turn on C-Like operators.. I'm sure Lazarus turns this on by default, but 
it's not the normal default for just FPC.  I know it is not the default because 
I just installed FPC and if would not compile the exactly 1 instance I used += 
until I went in and turn on C-Like operators.

As far as typing code goes,  I find all the begin's and end's to take more 
effort than anything else...  but I can type a block of
   Begin
   End
Else
   Begin
   End; 
Super fast now anyway... and I find that I defiantly PREFER to make the effort 
because the code is much more readable than things like python that don't use 
anything but indentation or C that uses the {} braces..   I find it so much 
easier to follow after the fact having begin and end than trying to follow a 
huge chain of braces which blend in way too easily with parenthesis ().  Also 
most coding has more to do with cutting and pasting than actually typing things 
out anyway.  Readability after the fact is simply WAY more important than how 
many keyboard keys you need to hit to get the code on the screen.

James

-Original Message-
From: fpc-pascal  On Behalf Of Rainer 
Stratmann
Sent: Wednesday, August 14, 2019 12:33 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] += property bug?

On Mittwoch, 14. August 2019 18:24:40 CEST Michael Van Canneyt wrote:
> On Wed, 14 Aug 2019, Ryan Joseph wrote:
> >> On Aug 14, 2019, at 12:04 PM, Rainer Stratmann  wrote:
> >>> It’s so
> >>> intuitive that basically all languages have adopted the syntax.
> >> 
> >> That is not true
> > 
> > All languages I use have them: Pascal, C, PHP, C#, Swift, Python, 
> > JavaScript. These are some of the most popular languages in the 
> > world right now. You’re fighting a losing battle sir.
> I don't see what the issue is ?
> 
> You do have +=  and the like. They exist, since about as long as I can 
> remember.

Didn't you know that Ryan?

> You just cannot use it on properties.
> 
> Properties have some other restrictions as well:
> 
> * You also cannot Use Inc() on integer properties,
> * or use Include()/Exclude() on set properties.
> * You also cannot do SomeRecordProp.X:=Y;
> * or pass them to functions that require var arguments.
> 
> And I'm probably forgetting some other limitations.
> 
> The += is just another one in the list of limitations of properties.
> 
> Basically any operation that requires an address is not allowed.
> That += is using an address is an implementation detail of the compiler.
> Same as Inc() or In/Exclude(). I don't know the exact reason for this 
> limitation, but it's bound to be a good one, otherwise it would have 
> been lifted a long time ago...
> 
> And if someone doesn't like these limitations of properties, (s)he can 
> use fields. No-one abolished those, after all.
> 
> Michael.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 14, 2019, at 12:33 PM, Rainer Stratmann  
> wrote:
> 
> Didn't you know that Ryan?

Yes, of course, I use them all the time and it’s why I was defending them from 
their critics (which I still find hard to believe even exist). Anyways, they 
exist and can be disabled using the directive Sven mentioned. Everyone wins. :)

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Sven Barth via fpc-pascal]

Michael Van Canneyt  schrieb am Mi., 14. Aug. 2019,
18:24:

> Basically any operation that requires an address is not allowed.
> That += is using an address is an implementation detail of the compiler.
> Same as Inc() or In/Exclude(). I don't know the exact reason for this
> limitation,
> but it's bound to be a good one, otherwise it would have been lifted a
> long time
> ago...
>

The restriction regarding taking an address was only started to be enforced
in 2.4.0 (see
https://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields)
and further extended to records in 2.6.0 (see
https://wiki.freepascal.org/User_Changes_2.6.0#Taking_the_address_of_fields_of_record_properties
). The idea is to have properties backed by a field and backed by methods
behave identically.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Rainer Stratmann]

On Mittwoch, 14. August 2019 18:24:40 CEST Michael Van Canneyt wrote:
> On Wed, 14 Aug 2019, Ryan Joseph wrote:
> >> On Aug 14, 2019, at 12:04 PM, Rainer Stratmann  wrote:
> >>> It’s so
> >>> intuitive that basically all languages have adopted the syntax.
> >> 
> >> That is not true
> > 
> > All languages I use have them: Pascal, C, PHP, C#, Swift, Python,
> > JavaScript. These are some of the most popular languages in the world
> > right now. You’re fighting a losing battle sir.
> I don't see what the issue is ?
> 
> You do have +=  and the like. They exist, since about as long as I can
> remember.

Didn't you know that Ryan?

> You just cannot use it on properties.
> 
> Properties have some other restrictions as well:
> 
> * You also cannot Use Inc() on integer properties,
> * or use Include()/Exclude() on set properties.
> * You also cannot do SomeRecordProp.X:=Y;
> * or pass them to functions that require var arguments.
> 
> And I'm probably forgetting some other limitations.
> 
> The += is just another one in the list of limitations of properties.
> 
> Basically any operation that requires an address is not allowed.
> That += is using an address is an implementation detail of the compiler.
> Same as Inc() or In/Exclude(). I don't know the exact reason for this
> limitation, but it's bound to be a good one, otherwise it would have been
> lifted a long time ago...
> 
> And if someone doesn't like these limitations of properties, (s)he can use
> fields. No-one abolished those, after all.
> 
> Michael.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 14, 2019, at 12:24 PM, Michael Van Canneyt  
> wrote:
> 
> I don't see what the issue is ?
> 
> You do have +=  and the like. They exist, since about as long as I can 
> remember.

I’m just responding to the fact Sven he regretted added them for some reason 
(and others now I’m learning). I just can’t understand that.

As per the original message I seriously thought it was a bug but there are 
technical implications apparently. I was going to fix it but there’s no 
interest in doing that so I’m just going to work around it for now. No problem.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Michael Van Canneyt]

On Wed, 14 Aug 2019, Ryan Joseph wrote:





On Aug 14, 2019, at 12:04 PM, Rainer Stratmann  
wrote:


It’s so
intuitive that basically all languages have adopted the syntax.


That is not true


All languages I use have them: Pascal, C, PHP, C#, Swift, Python, JavaScript. 
These are some of the most popular languages in the world right now. You’re 
fighting a losing battle sir.


I don't see what the issue is ?

You do have +=  and the like. They exist, since about as long as I can remember.

You just cannot use it on properties.

Properties have some other restrictions as well:

* You also cannot Use Inc() on integer properties, 
* or use Include()/Exclude() on set properties. 
* You also cannot do SomeRecordProp.X:=Y;

* or pass them to functions that require var arguments.

And I'm probably forgetting some other limitations.

The += is just another one in the list of limitations of properties.

Basically any operation that requires an address is not allowed.
That += is using an address is an implementation detail of the compiler.
Same as Inc() or In/Exclude(). I don't know the exact reason for this 
limitation,
but it's bound to be a good one, otherwise it would have been lifted a long time
ago...

And if someone doesn't like these limitations of properties, (s)he can use fields. 
No-one abolished those, after all.


Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 14, 2019, at 12:04 PM, Rainer Stratmann  
> wrote:
> 
>> It’s so
>> intuitive that basically all languages have adopted the syntax.
> 
> That is not true

All languages I use have them: Pascal, C, PHP, C#, Swift, Python, JavaScript. 
These are some of the most popular languages in the world right now. You’re 
fighting a losing battle sir.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Rainer Stratmann]

On Mittwoch, 14. August 2019 11:45:20 CEST Ryan Joseph wrote:
> > On Aug 14, 2019, at 11:41 AM, wkitt...@windstream.net wrote:
> > 
> > good reason?? because someone is too lazy to type 4 more characters? yes,
> > i'm counting the readability spaces which could easily be left out...
> yes, that’s exactly why. Programers got sick of wasting time typing
> redundant characters so they attacked the problem at the root.

I am so sick of typing all the characters...

No, your eyes get sick if you have to read C code.

If you had a real problem where there is no solution at the moment I could 
understand you. But there is no problem, and no one is preventing you from 
writing good and readable code.

> It’s so
> intuitive that basically all languages have adopted the syntax.

That is not true.

> I’m not
> saying you should but it’s going to  hurt Pascal if we ignore these kinds
> of trends.

Also not true.

> 
> Regards,
>   Ryan Joseph
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 14, 2019, at 11:52 AM, Joost van der Sluis  wrote:
> 
> Roflol... yeah... people do not use Pascal because they have to type:
> i := i + 1;
> 
> Sure.

I’m once again shocked that anyone would be against such syntaxes as += so 
maybe the compiler needs to put them behind a modeswitch. Given what Sven said 
I’m surprised they didn’t do this from the start. Even “out” is behind a mode 
switch after all.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Joost van der Sluis]

Op 14-08-19 om 17:45 schreef Ryan Joseph:

On Aug 14, 2019, at 11:41 AM, wkitt...@windstream.net wrote:

good reason?? because someone is too lazy to type 4 more characters? yes, i'm 
counting the readability spaces which could easily be left out...


yes, that’s exactly why. Programers got sick of wasting time typing redundant 
characters so they attacked the problem at the root. It’s so intuitive that 
basically all languages have adopted the syntax. I’m not saying you should but 
it’s going to  hurt Pascal if we ignore these kinds of trends.


Roflol... yeah... people do not use Pascal because they have to type:
i := i + 1;

Sure.

Thanks for the laugh, though. But completely off-topic. I shouldn't have 
responded.


Regards,

Joost.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 14, 2019, at 11:41 AM, wkitt...@windstream.net wrote:
> 
> good reason?? because someone is too lazy to type 4 more characters? yes, i'm 
> counting the readability spaces which could easily be left out...

yes, that’s exactly why. Programers got sick of wasting time typing redundant 
characters so they attacked the problem at the root. It’s so intuitive that 
basically all languages have adopted the syntax. I’m not saying you should but 
it’s going to  hurt Pascal if we ignore these kinds of trends.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[wkitty42]

On 8/14/19 10:54 AM, Ryan Joseph wrote:

Seriously? why is i := i + 1 better than i += 1 ? just more typing for such a
simple operation. All languages I use have adopted this syntax and for good
reason.


good reason?? because someone is too lazy to type 4 more characters? yes, i'm 
counting the readability spaces which could easily be left out...


/me tightens belt on asbestos britches...


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 13, 2019, at 11:09 AM, Sven Barth via fpc-pascal 
>  wrote:
> 
> In general the C operators are not desired. They where added way in the past 
> in a weak moment and I don't think they'd be added today if FPC wouldn't have 
> them already. 
> 

Seriously? why is i := i + 1 better than i += 1 ? just more typing for such a 
simple operation. All languages I use have adopted this syntax and for good 
reason.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Jonas Maebe]

On 13/08/2019 14:44, Martok wrote:
> Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal:
>> The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so
>> except for using a temp to avoid duplicate calculation of "a" in how far is 
>> this
>> not the long form? 
> 
> No, I meant it doesn't re-parse as its long form, which is why it has some
> limitations. In this case for example handle_propertysym does not know it is
> actually seeing an assignment.

If the compiler would do that, the behaviour could change from what you
would expect from glancing over the code, because the left-hand side
would be evaluated twice instead of once.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Sven Barth via fpc-pascal]

Martok  schrieb am Di., 13. Aug. 2019, 14:44:

> Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal:
> > The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b",
> so
> > except for using a temp to avoid duplicate calculation of "a" in how far
> is this
> > not the long form?
>
> No, I meant it doesn't re-parse as its long form, which is why it has some
> limitations. In this case for example handle_propertysym does not know it
> is
> actually seeing an assignment.
>
> I don't think the compiler can do this? Macros are expanded on the scanner
> level, token stream injection is not a thing in FPC, AFAICS?
>

It could be done, but property support for the C operators is not
*desired*. See the entry of the function you posted: properties are
explicitly rejected.

In general the C operators are not desired. They where added way in the
past in a weak moment and I don't think they'd be added today if FPC
wouldn't have them already.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Martok]

Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal:
> The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so
> except for using a temp to avoid duplicate calculation of "a" in how far is 
> this
> not the long form? 

No, I meant it doesn't re-parse as its long form, which is why it has some
limitations. In this case for example handle_propertysym does not know it is
actually seeing an assignment.

I don't think the compiler can do this? Macros are expanded on the scanner
level, token stream injection is not a thing in FPC, AFAICS?

-- 
Regards,
Martok


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Sven Barth via fpc-pascal]

Martok  schrieb am Mo., 12. Aug. 2019, 10:18:

> Am 12.08.2019 um 09:40 schrieb Michael Van Canneyt:
> >
> > This question pops up from time to time since 15 years if not more.
>
> Fun fact: questions asking why this doesn't work have a higher Google
> ranking
> than the manual for "COPERATORS" ;-)
>
> @Ryan: as with all things FPC, ignore the manual, read the parser:
> <
> https://github.com/graemeg/freepascal/blob/4e6c609/compiler/pexpr.pas#L221
> >
>
> Turns out c-operators do not actually translate to their long form but
> instead
> have special, duplicated handling. Because of course they do.
>

The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so
except for using a temp to avoid duplicate calculation of "a" in how far is
this not the long form?

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Martok]

Am 12.08.2019 um 09:40 schrieb Michael Van Canneyt:
> 
> This question pops up from time to time since 15 years if not more.

Fun fact: questions asking why this doesn't work have a higher Google ranking
than the manual for "COPERATORS" ;-)

@Ryan: as with all things FPC, ignore the manual, read the parser:


Turns out c-operators do not actually translate to their long form but instead
have special, duplicated handling. Because of course they do.


-- 
Regards,
Martok


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Michael Van Canneyt]

On Sun, 11 Aug 2019, Ryan Joseph wrote:





On Aug 11, 2019, at 3:59 PM, Alexander Grotewohl  wrote:

d.x += 10; // makes even more sense



rect.axisX += 10 is a compound statement. See it makes perfect sense. :) I 
still don’t understand why the compiler and Delphi apparently thinks this is 
such a crazy idea. It's just normal stuff imo.


This question pops up from time to time since 15 years if not more.

Some operators need actual variable addresses. A property does not have an 
address.
It also becomes difficult if you have interfaces & classes or other
overloaded things.

The compiler people can give a more detailed answer.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 11, 2019, at 3:59 PM, Alexander Grotewohl  wrote:
> 
> d.x += 10; // makes even more sense

Ok, you win. Here’s more or less the full snippet.

type
  TRectHelper = record helper for TVec4
private
  procedure SetAxisX(newValue: TScalar); inline;
public
  function MinX: TScalar; inline;
  function MinX: TScalar; inline;
  property AxisX: TScalar read MinX write SetAxisX;
  end;

function TRectHelper.MinX: TScalar;
begin
  result := v[0];
end;

function TRectHelper.MaxX: TScalar;
begin
  result := v[2];
end;

procedure TRectHelper.SetAxisX(newValue: TScalar);
begin
  v[0] += newValue;
  v[2] += newValue;
end;

==

rect.axisX += 10 is a compound statement. See it makes perfect sense. :) I 
still don’t understand why the compiler and Delphi apparently thinks this is 
such a crazy idea. It's just normal stuff imo.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Alexander Grotewohl]

d.x += 10; // makes even more sense

On 8/11/2019 2:21 PM, Ryan Joseph wrote:



On Aug 11, 2019, at 11:41 AM, Sven Barth via fpc-pascal 
 wrote:

This is forbidden by design.

Why? It makes sense it should resolve to: d.setter(d.getter + 10) but maybe 
there’s a problem?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Rainer Stratmann]

On Sonntag, 11. August 2019 12:21:18 CEST Ryan Joseph wrote:
> > On Aug 11, 2019, at 11:41 AM, Sven Barth via fpc-pascal
> >  wrote:
> > 
> > This is forbidden by design.
> 
> Why? It makes sense it should resolve to: d.setter(d.getter + 10) but maybe
> there’s a problem?

For me it seems that you can solve the issue easily with existing 
technologies.
Moreover the code will be better to read and to handle in my opinion.
Otherwise your code will be likewise C code with much information in the 
smallest place. That is not good to handle in my opinion.
I have some experience with C code. It is not my preferred language.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Ryan Joseph]

> On Aug 11, 2019, at 11:41 AM, Sven Barth via fpc-pascal 
>  wrote:
> 
> This is forbidden by design.

Why? It makes sense it should resolve to: d.setter(d.getter + 10) but maybe 
there’s a problem?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Sven Barth via fpc-pascal]

Am 11.08.2019 um 18:33 schrieb Ryan Joseph:

Is this a bug? It should resolve to:

d.setter(d.getter + 10)

but it doesn’t seem to be working.



{$mode objfpc}
{$modeswitch advancedrecords}

program test;

type
   TData = record
 x: integer;
   end;

type
   TVec2Helper = record helper for TData
 function Getter: integer;
 procedure Setter(newValue: integer);
 property Get: integer read Getter write Setter;
   end;

function TVec2Helper.Getter: integer;
begin
   result := x;
end;

procedure TVec2Helper.Setter(newValue: integer);
begin
   x := newValue;
end;

var
   d: TData;
begin
   d.get += 10; // ERROR: Variable identifier expected
end.

This is forbidden by design.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] += property bug?

[Bart]

On Sun, Aug 11, 2019 at 6:33 PM Ryan Joseph  wrote:

> begin
>   d.get += 10;  // ERROR: Variable identifier expected
> end.

AFAIK you cannot do that to a property (not even if it maps to a field).
Delphi does not allow it either IIRC.

-- 
Bart
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal