[fpc-devel] (ref types / circles) Re: Defer keyword

[Sven Barth]

Am 09.05.2021 um 16:58 schrieb Ryan Joseph via fpc-devel:
>
>> On May 9, 2021, at 3:40 AM, Sven Barth <pascaldragon at googlemail.com> wrote:
>>
>> It seems that you don't work much with classes then. If one disallows the assignment of a reference counted class to a non-reference counted one then you can't use e.g. TStringList.Objects. There is also the problem of method pointers, which essentially only have a Pointer as Self data. Also a reference might escape in a parent class (for this example I'll use the syntax I used in my branch):
> I use classes all the time but I thought that any assignments or passing to function args call the management operators. So if you pass a managed class to a TStringList.Add for example then AddRef will indeed by called. You're saying this isn't the case? I know the FGL classes can work with ref counted objects so why is it any different if a class type was managed and then passed into one of these types?

Why should they? You pass the reference to a non-reference counted 
parameter/field/variable, the reference count is increased and then 
what? It sits there for the remaining life time of the program, because 
nothing decrements the reference count?

>>> Anyways I wrote up a little wiki with some potential implementation notes about a default property (which overlaps on the "defaults implements" as traits stuff). Important points are restricting what types can be default properties (classes and maybe/probably typed pointers) and limiting hoisting to subscripting, so it's kind of like the -> operator overload in C++.
>>>
>>> https://github.com/genericptr/freepascal/wiki/Default-property
>> It shouldn't hoist only public members, it should hoist according to the visibility rules (thus the hoisting depends on the callsite), otherwise it won't behave like Pascal classes do and thus we can forget it right away.
> So this means if the property is in the private section it looks at private visibility in the parent class? Yeah that's probably right we need to do that.

You should reread the visibility rules of Object Pascal:
- private: identifier is visible inside the whole unit
- strict private: identifier is only visible inside code of the class
- protected: identifier is visible inside the whole unit as well as 
inside descendants of the class as well as type helpers
- strict protected: identifier is visible inside code of the class, 
inside descendants of the class as well as type helpers
- public: identifier is visible in the whole unit and (if it's declared 
in the interface section) any unit that includes that unit
- published: like public, but with RTTI data

> Some things:
>
> 1) What do read/write access even mean in the context of the default properties? The terms don't really make much sense given what the the property does. Right now the property could be read only or write only but those don't really have any affect on the hoisting process itself so it's kind of deceptive. Methods are always "read-only" but i guess you could hoist fields/properties and inherit the access level of the default property. No idea if that's helpful or just adding needless complexity. Any ideas?
Property accessors indeed don't really make sense. Maybe a "default 
field" would be better than a "default property".

> 2) I also think there needs to be another name for the feature than "default property" since this term is already used for array indexers and could even be used for something like traits in the future (traits would be reusing much of this code). I need to add some enum names and default_property is already used so I need to think of something else.
>
> 3) What about allowing type pointers as default properties? This should be possible and is in the spirit of the feature anyways, that is ref counting. We may need to add some additional logic to properties (just internally) so that they can be used with pointers but I'm not sure about that yet.
Pointers are only useful if the ^ "operator" is hoisted as well.

Regards,
Sven