Am 09.05.2021 um 16:58 schrieb Ryan Joseph via fpc-devel:
On May 9, 2021, at 3:40 AM, Sven Barth <pascaldra...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
