[fpc-pascal] Interface delegates and the implements property specifier

[Sven Barth]

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.

Regards,
Sven