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
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,
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
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
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 +=.
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
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
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
> 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.
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
>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
> 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
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
> 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
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
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
> 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
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
> 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
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
> 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.
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
> 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
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
> 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
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
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?
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,
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"
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
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
> 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:
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
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
> 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
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;
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
___
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
38 matches
Mail list logo
