[fpc-pascal] Interface delegates and the implements property specifier
pascaldragon at googlemail.com
Fri Dec 27 18:01:47 CET 2019
Am 26.12.2019 um 20:32 schrieb Ryan Joseph via fpc-pascal:
>> On Dec 24, 2019, at 1:16 AM, Sven Barth via fpc-pascal <fpc-pascal at lists.freepascal.org> wrote:
>> Basically, yes, though of course syntax, implementation and behavior need to be nicely defined first. For example there is the difference whether something is added at declaration time of the class or the creation time of the class (though that might be the difference between mixins and aspect oriented programming).
> I hope you're all having a wonderful Christmas season. :)
> Some more thoughts on this:
> - My initial thought was that importing would happen at definition time simply because I don't know what the difference would be to import at declaration time.
To be clear: with declaration time I mean when the type is written (" =
class ... end") versus creation time (either "var x: tmyclass" or "x :=
tmyclass .create"). The difference would be that the user of the class
would decide what is supported instead of the declarer of the class.
Adding something at creation time would of course require that the
functionality can only be accessed dynamically (similar to GetInterface,
though like that it can be hidden behind e.g. the "as" operator) and
that the functionality needs to be independant of the existing class.
> - Importing fields/properties is easy because we can just add symbols to the symbol table but I'm not sure what it means in terms of the compiler to import a method from another class. The method needs to be cloned or perhaps synthesized as I've seen the term used in the compiler. Because the traits aren't actually allocated like a class or record we need to copy the code out into the class that uses them.
You don't need to do any copying of the functions. You need to partition
the instance so that fields that belong to a specific trait are grouped
together and then you pass an adjusted self pointer to the trait's
methods so that this only sees accesses its own fields (and properties
are the same as methods or field access: use the correct Self part).
What I'm still missing however is a real use case. What you have
presented as an example can just as easily be done with the existing
delegates. And just to avoid having to cast the instance to the
interface is in my opinion not enough reason for a new feature.
More information about the fpc-pascal