Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 5:40 PM Ryan Joseph wrote: > I’m not sure if it’s a bug or not so I’ll wait for the compiler teams > response and I don’t care either way, I just want constref to work. :) > I looked into this some more, and it's almost certainly completely intentional behavior as Delphi

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 5:40 PM Ryan Joseph wrote: > I just want constref to work. :) > Pretty sure taking "vs_constref" out of the set here in defcmp.pas would do it.

Re: [fpc-devel] [] property overloads

> On Jul 9, 2019, at 5:32 PM, Ben Grasset wrote: > > I don't know if I completely agree with this part in a general sense. There's > plenty of perfectly valid uses for properties that are nothing like the > straightforward "make something act like an array" stuff: > I guess I could see

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 4:18 PM Ryan Joseph wrote: > it goes against the idea of properties anyways. > I don't know if I completely agree with this part in a general sense. There's plenty of perfectly valid uses for properties that are nothing like the straightforward "make something act like an

Re: [fpc-devel] [] property overloads

> On Jul 9, 2019, at 4:09 PM, Ben Grasset wrote: > > I don't know if it necessarily *is* a bug. > > It would definitely be if it worked with literals as input, which is the > impression I had based on what someone reported previously for some reason, > but again, after testing it myself

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 3:17 PM Ryan Joseph wrote: > Please post an example of the var/out bug if you don’t mind. Just to be > sure. > I don't know if it necessarily *is* a bug. It would definitely be if it worked with literals as input, which is the impression I had based on what someone

Re: [fpc-devel] [] property overloads

> On Jul 9, 2019, at 3:15 PM, Ben Grasset wrote: > > Well, they *are* accepted for things that would normally be valid with "var" > and "out" in other scenarios (by which I mean, variables, not numeric > literals / e.t.c) Please post an example of the var/out bug if you don’t mind. Just to

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 2:58 PM Ryan Joseph wrote: > Ok, I'm confused now. I thought that var/out were accepted but I just > tested myself and indeed they are rejected. > Well, they *are* accepted for things that would normally be valid with "var" and "out" in other scenarios (by which I mean,

Re: [fpc-devel] [] property overloads

> On Jul 9, 2019, at 12:59 PM, Ben Grasset wrote: > > Well, I just checked, and with "out" and "var" for a getter with an array > property it actually doesn't compile if you pass a literal. Which is good as > at least it behaves logically. > > That said, I'm unsure why setters need a

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 12:59 PM Ben Grasset wrote: > On Tue, Jul 9, 2019 at 12:32 PM Ryan Joseph wrote: > >> So do I need to open another bug report for for this out/var/constref >> stuff? We already have https://bugs.freepascal.org/view.php?id=28949 but >> that’s just about the overloading

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 12:32 PM Ryan Joseph wrote: > So do I need to open another bug report for for this out/var/constref > stuff? We already have https://bugs.freepascal.org/view.php?id=28949 but > that’s just about the overloading bugs. > > I think it needs to be something like var/out should

Re: [fpc-devel] [] property overloads

> On Jul 9, 2019, at 12:28 PM, Ben Grasset wrote: > > As far as the "out", I'd say that is a lexical/parser bug certainly, although > it does not seem to actually *behave* like "out" in the case of something like > So do I need to open another bug report for for this out/var/constref stuff?

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 12:11 PM Ryan Joseph wrote: > Why does that require a special switch? Also, I thought it was determined > that allowed “out” in array properties was a bug? > Not sure about the exact history of VARPROPSETTER. It's an old Delphi thing, rarely used nowadays though. As far

Re: [fpc-devel] [] property overloads

> On Jul 9, 2019, at 12:09 PM, Ben Grasset wrote: > > It works for constref if you use {$VARPROPSETTER ON}. > > The docs for that directive are slightly incorrect, I just noticed, also: > > https://www.freepascal.org/docs-html/current/prog/progsu121.html > Where it says "Enable use of

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 9:39 AM Ryan Joseph wrote: > Another thing regarding array properties. If I use constref on the setter > I get an error "Illegal symbol for property access”. Is there any reason > why the setter can’t be constref? > It works for constref if you use {$VARPROPSETTER ON}.

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Di., 9. Juli 2019, 15:39: > Another thing regarding array properties. If I use constref on the setter > I get an error "Illegal symbol for property access”. Is there any reason > why the setter can’t be constref? If not I’d like to change this with my > array properties

Re: [fpc-devel] [] property overloads

Another thing regarding array properties. If I use constref on the setter I get an error "Illegal symbol for property access”. Is there any reason why the setter can’t be constref? If not I’d like to change this with my array properties patch. Making it inline properly avoids the copy but you

Re: [fpc-devel] [] property overloads

> On Jul 8, 2019, at 5:27 PM, Sven Barth via fpc-devel > wrote: > > Well, in theory you could use a read only index property that returns a > pointer and a write only index property that takes the type as is. > But overloading only based on the result type is not supported. > I was

Re: [fpc-devel] [] property overloads

> On Jul 8, 2019, at 6:11 PM, Ben Grasset wrote: > > Also, here's a longer (but much better because it doesn't require the data > type provided by the user to itself be directly assignable to a pointer) > version of that: > That’s getting creative, I like it, thanks. Regards, Ryan

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 3:47 PM Ben Grasset wrote: > On Mon, Jul 8, 2019 at 2:22 PM Ryan Joseph wrote: > >> and it will actually write to the actual record in the array and not a >> returned copy. However due to how the properties are currently structured >> this means we can’t use the setter

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Mo., 8. Juli 2019, 18:04: > > > > On Jul 8, 2019, at 11:07 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > As Pascal does not allow differentiating between result types this > indeed needs to be/stay forbidden. > > > > There actually is a

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 2:22 PM Ryan Joseph wrote: > and it will actually write to the actual record in the array and not a > returned copy. However due to how the properties are currently structured > this means we can’t use the setter without passing pointers > Ah, I see what you mean. Note

Re: [fpc-devel] [] property overloads

> On Jul 8, 2019, at 2:16 PM, Ben Grasset wrote: > > One thing I might point out as a general tip is that you don't really > necessarily *need* an array-style index for the kind of access you seem to be > going for, especially if using something like TValue which has a lot of > assignment

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 12:04 PM Ryan Joseph wrote: > There actually is a need to distinguish between getters/setters but the > way property syntax works we’re forced for the return type to be the same > as the input for the setter. This is a problem I faced before where I want > the getter to

Re: [fpc-devel] [] property overloads

> On Jul 8, 2019, at 11:07 AM, Sven Barth via fpc-devel > wrote: > > As Pascal does not allow differentiating between result types this indeed > needs to be/stay forbidden. > There actually is a need to distinguish between getters/setters but the way property syntax works we’re forced

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Mo., 8. Juli 2019, 16:10: > I just encountered something to consider. Should a property be > overloadable if the names/args are the same but the return type is > different? I think if they are not the same access type (i.e. read/write) > then it could work (not sure about

Re: [fpc-devel] [] property overloads

I just encountered something to consider. Should a property be overloadable if the names/args are the same but the return type is different? I think if they are not the same access type (i.e. read/write) then it could work (not sure about the parsing though) but if both are the same access then

Re: [fpc-devel] [] property overloads

> On Jul 6, 2019, at 4:28 PM, Ondrej Pokorny wrote: > >> I’m sorry, I didn’t know about your report. > > I though you checked it when you answered upon it. But no problem - it > happens quite often that people answer my posts without actually reading > them. On the other hand it is quite

Re: [fpc-devel] [] property overloads

On 06.07.2019 22:12, Ryan Joseph wrote: On Jul 6, 2019, at 4:09 PM, Ondrej Pokorny wrote: On 06.07.2019 20:03, Ryan Joseph wrote: Yeah that’s correct. Here’s my bug report: https://bugs.freepascal.org/view.php?id=35809 Did you just create a duplicate bug report to the one I linked in this

Re: [fpc-devel] [] property overloads

> On Jul 6, 2019, at 4:09 PM, Ondrej Pokorny wrote: > > On 06.07.2019 20:03, Ryan Joseph wrote: >> Yeah that’s correct. >> >> Here’s my bug report: >> >> https://bugs.freepascal.org/view.php?id=35809 > > Did you just create a duplicate bug report to the one I linked in this thread > before

Re: [fpc-devel] [] property overloads

On 06.07.2019 20:03, Ryan Joseph wrote: Yeah that’s correct. Here’s my bug report: https://bugs.freepascal.org/view.php?id=35809 Did you just create a duplicate bug report to the one I linked in this thread before ( https://lists.freepascal.org/pipermail/fpc-devel/2019-July/041350.html )

Re: [fpc-devel] [] property overloads

> On Jul 6, 2019, at 12:14 PM, Michael Van Canneyt > wrote: > > Why should this declaration not be allowed ? > > Only the first GetValue() should be called, of course. > > i.e. statement 1: > A:=Values[MyVariant] > must work > > but e.g. statement 2: > A:=Values[MyVariant1,MyVariant2] >

Re: [fpc-devel] [] property overloads

On Sat, 6 Jul 2019, Ryan Joseph wrote: Sorry to ask again but has it been decided that this code should *not* be allowed for ObjFPC mode? I’ll file a bug report right now if so. It will break existing code but when my patch gets applied it can be added back using proper properties.

Re: [fpc-devel] [] property overloads

Sorry to ask again but has it been decided that this code should *not* be allowed for ObjFPC mode? I’ll file a bug report right now if so. It will break existing code but when my patch gets applied it can be added back using proper properties. function GetValue(k0: variant): TJSON;

Re: [fpc-devel] [] property overloads

> On Jul 2, 2019, at 3:20 AM, Ondrej Pokorny wrote: > > This code is never executed for an array property. The "[" for an array > property is processed directly in handle_propertysym: > > procedure handle_propertysym(propsym : tpropertysym;st : TSymtable;var p1 > : tnode); > var >

Re: [fpc-devel] [] property overloads

On Tue, 2 Jul 2019, Ondrej Pokorny wrote: On 02.07.2019 09:10, Michael Van Canneyt wrote: I had a quick peek in the compiler sources. In pexpr.pas, before processing the [, the compiler calls this:     { we need the resultdef }     do_typecheckpass_changed(p1,nodechanged); In my

Re: [fpc-devel] [] property overloads

On 02.07.2019 09:10, Michael Van Canneyt wrote: I had a quick peek in the compiler sources. In pexpr.pas, before processing the [, the compiler calls this:     { we need the resultdef }     do_typecheckpass_changed(p1,nodechanged); In my opinion, this routine will/should error out if

Re: [fpc-devel] [] property overloads

On 02.07.2019 08:17, Michael Van Canneyt wrote: On Tue, 2 Jul 2019, Ondrej Pokorny wrote: I happened to study this part of FPC code back in 2015 when I worked on issue #28820. I can say that FPC directly transfers indexed properties Stop... How does FPC decide it is an indexed property ?

Re: [fpc-devel] [] property overloads

On Tue, 2 Jul 2019, Michael Van Canneyt wrote: On Tue, 2 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 23:25, Michael Van Canneyt wrote: I understand. But all depends on how the compiler parses and evaluates this. Let me put brackets to make it more clear: is MyTest.StringArray[i]

Re: [fpc-devel] [] property overloads

On Tue, 2 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 23:25, Michael Van Canneyt wrote: I understand. But all depends on how the compiler parses and evaluates this. Let me put brackets to make it more clear: is MyTest.StringArray[i] parsed & evaluated as (MyTest.StringArray)([(i)])

Re: [fpc-devel] [] property overloads

On 01.07.2019 23:25, Michael Van Canneyt wrote: I understand. But all depends on how the compiler parses and evaluates this. Let me put brackets to make it more clear: is MyTest.StringArray[i] parsed & evaluated as (MyTest.StringArray)([(i)]) or as (MyTest.StringArray[(i)]) In the former

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 21:04, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 19:38, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul

Re: [fpc-devel] [] property overloads

On 01.07.2019 21:04, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: If the compiler encounters "Mytest.StringArray" it can be evaluated only as the non-indexed overload. Well... We can of course discuss forever, and still not agree. I suggest we let the compiler people

Re: [fpc-devel] [] property overloads

On 01.07.2019 21:04, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 19:38, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: From the above example

Re: [fpc-devel] [] property overloads

On 01.07.2019 21:04, Michael Van Canneyt wrote: If the compiler encounters "Mytest.StringArray" it can be evaluated only as the non-indexed overload. Well... We can of course discuss forever, and still not agree. I suggest we let the compiler people have the last word on this. They know best.

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 19:38, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 15:57, Ryan Joseph wrote:   TTest = class   public    

Re: [fpc-devel] [] property overloads

On 01.07.2019 19:38, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 15:57, Ryan Joseph wrote:   TTest = class   public     // ...     property StringArray[Index:

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 15:57, Ryan Joseph wrote: Yes, I’ve made a patch to allow overriding the actual property (https://bugs.freepascal.org/view.php?id=35772).

Re: [fpc-devel] [] property overloads

On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 15:57, Ryan Joseph wrote: Yes, I’ve made a patch to allow overriding the actual property (https://bugs.freepascal.org/view.php?id=35772). Very good! Just a short question: does your

Re: [fpc-devel] [] property overloads

On 01.07.2019 18:21, Ryan Joseph wrote: On Jul 1, 2019, at 12:08 PM, Ondrej Pokorny wrote: Very good! Just a short question: does your solution allow one overload without array indexes? It is very useful as a for-in enumerator of the array property: TTest = class public // ...

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 15:57, Ryan Joseph wrote: Yes, I’ve made a patch to allow overriding the actual property (https://bugs.freepascal.org/view.php?id=35772). Very good! Just a short question: does your solution allow one overload without array indexes?

Re: [fpc-devel] [] property overloads

> On Jul 1, 2019, at 12:08 PM, Ondrej Pokorny wrote: > > Very good! Just a short question: does your solution allow one overload > without array indexes? It is very useful as a for-in enumerator of the array > property: > > TTest = class > public > // ... > property

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019 11:38:31 -0400 Ryan Joseph wrote: > > On Jul 1, 2019, at 7:56 AM, Ondrej Pokorny > > wrote: > > > > type > > TValue = record A: Integer end; > > TMyClass = class > > function GetValue(index: integer): TValue; > > function GetValue(index: string): TValue; > >

Re: [fpc-devel] [] property overloads

On 01.07.2019 15:57, Ryan Joseph wrote: Yes, I’ve made a patch to allow overriding the actual property (https://bugs.freepascal.org/view.php?id=35772). Very good! Just a short question: does your solution allow one overload without array indexes? It is very useful as a for-in enumerator of

Re: [fpc-devel] [] property overloads

On 01.07.2019 17:38, Ryan Joseph wrote: On Jul 1, 2019, at 7:56 AM, Ondrej Pokorny wrote: type TValue = record A: Integer end; TMyClass = class function GetValue(index: integer): TValue; function GetValue(index: string): TValue; property Index[aindex: integer]: TValue read

Re: [fpc-devel] [] property overloads

> On Jul 1, 2019, at 7:56 AM, Ondrej Pokorny wrote: > > type > TValue = record A: Integer end; > TMyClass = class > function GetValue(index: integer): TValue; > function GetValue(index: string): TValue; > property Index[aindex: integer]: TValue read GetValue; default; > end;

Re: [fpc-devel] [] property overloads

> On Jul 1, 2019, at 7:56 AM, Ondrej Pokorny wrote: > > Properties do allow overloading of the parameters. > > You only must not declare the overloaded properties but declare overloaded > getters/setters. The compiler will silently accept them. > >

Re: [fpc-devel] [] property overloads

On 20.06.2019 19:57, Ryan Joseph wrote: I just had some plans for a cool JSON class thwarted because apparently [] properties don’t allow overloading of the parameters. Can we allow multiple default properties as long as their parameters are different? Properties do allow overloading of the

Re: [fpc-devel] [] property overloads

On Thu, 27 Jun 2019, Ryan Joseph wrote: Another user just reported that default properties can ALREADY be overloaded (https://bugs.freepascal.org/view.php?id=35772). The syntax is kind of awkward (thus we weren’t able to infer it) but it seems to work. Does this mean we should ignore my

Re: [fpc-devel] [] property overloads

Another user just reported that default properties can ALREADY be overloaded (https://bugs.freepascal.org/view.php?id=35772). The syntax is kind of awkward (thus we weren’t able to infer it) but it seems to work. Does this mean we should ignore my patch or still go with it because of Delphi

Re: [fpc-devel] [] property overloads

I’m putting this into the pipeline and I’ll make a better patch after it’s reviewed since I’m not sure I got everything right. https://bugs.freepascal.org/view.php?id=35772 Regards, Ryan Joseph ___ fpc-devel maillist -

Re: [fpc-devel] [] property overloads

> On Jun 21, 2019, at 1:59 PM, Ryan Joseph wrote: > > Even though overloads are allowed the actual name isn’t overloaded so you > MUST access without the name to get overloading affects. I didn’t overload > the actual name because properties aren’t really functions and as such don’t > use

Re: [fpc-devel] [] property overloads

Can anyone test this to see if it’s ok? Not sure I got everything correct and I still need some new error messages that make more sense (see the writeln’s I left in) Even though overloads are allowed the actual name isn’t overloaded so you MUST access without the name to get overloading

Re: [fpc-devel] [] property overloads

Marcus Marques da Rocha schrieb am Fr., 21. Juni 2019, 12:24: > It is possible to do that using variant type. I have done it as below: > Though this is not very type safe. So a correct solution in the compiler for overloading is definitely desired. Regards, Sven >

Re: [fpc-devel] [] property overloads

It is possible to do that using variant type. I have done it as below: property DocumentElementChildNodes[Index1: Variant] : TPXMLNode read getChildNode; default; function TPXMLNode.getChildNode(Index1 : Variant): TPXMLNode; begin   Result := nil;   if assigned(Self) and assigned(FChildNodes)

Re: [fpc-devel] [] property overloads

On Thu, 20 Jun 2019, Ryan Joseph wrote: On Jun 20, 2019, at 4:59 PM, Sven Barth via fpc-devel wrote: It will need to be be allowed for Delphi compatibility anyway: https://bugs.freepascal.org/view.php?id=29056 Well that settles it. ;) Indeed. You can be sure that patches for this

Re: [fpc-devel] [] property overloads

> On Jun 20, 2019, at 4:59 PM, Sven Barth via fpc-devel > wrote: > > It will need to be be allowed for Delphi compatibility anyway: > https://bugs.freepascal.org/view.php?id=29056 > Well that settles it. ;) Regards, Ryan Joseph ___

Re: [fpc-devel] [] property overloads

Michael Van Canneyt schrieb am Do., 20. Juni 2019, 22:05: > But maybe the compiler people can see a reason why this should not be > allowed. > It will need to be be allowed for Delphi compatibility anyway: https://bugs.freepascal.org/view.php?id=29056 Regards, Sven >

Re: [fpc-devel] [] property overloads

> On Jun 20, 2019, at 3:58 PM, Michael Van Canneyt > wrote: > > The point is that there is in my example only 'Values' which is a unique > name. Making that 'Default' just means that the 'Values' keyword can be left > out. > making the 'Values' array the single default. Got it. The default

Re: [fpc-devel] [] property overloads

On Thu, 20 Jun 2019, Ryan Joseph wrote: On Jun 20, 2019, at 2:17 PM, Michael Van Canneyt wrote: IMHO this goes contrary to what the word 'default' means. There can be only 1 default. I think the name of “default” was probably a mistake and it should have been “nameless” or something

Re: [fpc-devel] [] property overloads

> On Jun 20, 2019, at 2:17 PM, Michael Van Canneyt > wrote: > > IMHO this goes contrary to what the word 'default' means. There can be only > 1 default. I think the name of “default” was probably a mistake and it should have been “nameless” or something similar. Not sure why it was chosen

Re: [fpc-devel] [] property overloads

On Thu, 20 Jun 2019, Ryan Joseph wrote: I just had some plans for a cool JSON class thwarted because apparently [] properties don’t allow overloading of the parameters. Can we allow multiple default properties as long as their parameters are different? I know there’s not overloading of