+= property bug?

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Michael Van Canneyt


On Wed, 14 Aug 2019, Ryan Joseph wrote:

>
>
>> On Aug 14, 2019, at 12:04 PM, Rainer Stratmann <[hidden email]> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Ryan Joseph-2


> On Aug 14, 2019, at 12:24 PM, Michael Van Canneyt <[hidden email]> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Rainer Stratmann
In reply to this post by Michael Van Canneyt
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 <rainerstratmann@t-
online.de> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Free Pascal - General mailing list
In reply to this post by Ryan Joseph-2
Ryan Joseph <[hidden email]> schrieb am Mi., 14. Aug. 2019, 18:04:


> On Aug 14, 2019, at 11:52 AM, Joost van der Sluis <[hidden email]> 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.

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... 

And "out" is behind a modeswitch because modes like TP and ISO don't know that concept. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Free Pascal - General mailing list
In reply to this post by Michael Van Canneyt
Michael Van Canneyt <[hidden email]> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Ryan Joseph-2
In reply to this post by Rainer Stratmann


> On Aug 14, 2019, at 12:33 PM, Rainer Stratmann <[hidden email]> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Zaaphod
In reply to this post by Rainer Stratmann
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 <[hidden email]> On Behalf Of Rainer Stratmann
Sent: Wednesday, August 14, 2019 12:33 PM
To: FPC-Pascal users discussions <[hidden email]>
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 <rainerstratmann@t-
online.de> 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  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Ryan Joseph-2


> On Aug 14, 2019, at 2:53 PM, James Richters <[hidden email]> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Zaaphod
In reply to this post by Free Pascal - General mailing list

>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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Zaaphod
In reply to this post by Ryan Joseph-2
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 <[hidden email]> On Behalf Of Ryan Joseph
Sent: Wednesday, August 14, 2019 2:58 PM
To: FPC-Pascal users discussions <[hidden email]>
Subject: Re: [fpc-pascal] += property bug?



> On Aug 14, 2019, at 2:53 PM, James Richters <[hidden email]> 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  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Ryan Joseph-2


> On Aug 14, 2019, at 3:15 PM, James Richters <[hidden email]> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Bart-48
In reply to this post by Zaaphod
On Wed, Aug 14, 2019 at 9:03 PM James Richters
<[hidden email]> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Bernd Oppolzer
In reply to this post by wkitty42
Am 14.08.2019 um 17:41 schrieb [hidden email]:

> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Zaaphod
In reply to this post by Bart-48
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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Martin Friebe
In reply to this post by Bernd Oppolzer
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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Zaaphod
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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Free Pascal - General mailing list
In reply to this post by Jean SUZINEAU
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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: += property bug?

Rainer Stratmann
In reply to this post by Ryan Joseph-2
On Mittwoch, 14. August 2019 14:15:51 CEST Ryan Joseph wrote:
> > On Aug 14, 2019, at 12:33 PM, Rainer Stratmann
> > <[hidden email]> 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  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12