Am 09.05.2021 um 16:58 schrieb Ryan Joseph via fpc-devel:

On May 9, 2021, at 3:40 AM, Sven Barth <> 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++.
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.

fpc-devel maillist  -

Reply via email to