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

[Ryan Joseph]

> On May 10, 2021, at 3:05 PM, Sven Barth via fpc-devel <fpc-devel at lists.freepascal.org> wrote:
> 
> 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?

I see what you mean. The FGL containers also call Finalize though when the container is freed so it does indeed keep balanced.

Lets focus on the record approach for now then. I don't think I know enough to understand where are the pitfalls are.

> 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

yes, yes, I know. I thought we'd do something different.

> 
>> 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".

"Default field" is certainly more unique and thus better. We'll have to think about this more.

> 
>> 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.

I meant to say pointers to records so yes the ^. would need to be there. I haven't looked into how this would be implemented but I got it working with classes for now. It would be nice to make pointers to records be possible for smart pointers so I'll look into that later.

Regards,
	Ryan Joseph