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

[Ryan Joseph]

> On Dec 27, 2019, at 10:01 AM, Sven Barth via fpc-pascal <fpc-pascal at lists.freepascal.org> wrote:
> 
> 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.

Got it.

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

Can you explain or gives some function names of where/how the importation of fields/methods happens for inheritance? For fields I'm seeing that the struct data size expands when a super class is parsed and then in searchsym_in_class the correct symbol is found but I don't know what happens after that. The data must be copied at some point but I don't know when.

For method calling I think you're saying we merely pass a different self pointer depending on which class in the hierarchy makes the call.

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

It's really just about the namespace and avoiding deeply nested this.that.do kind of syntax. We could accomplish this using just plain records, no need to even get involved with the complicated interface syntax. According to the wiki https://en.wikipedia.org/wiki/Trait_(computer_programming) lots of other languages are having this need to build component like systems and want a syntax that formalizes the concept.

Adriaan, what was your idea you had in mind when you brought this up?

========================

program test;

type
  TBrain = record
    procedure Eat;
    procedure Fight;
  end;

type
  TPhysics = record
    x, y, z: float;
    procedure Apply;
  end;

type
  TPerson = class
    physics: TPhysics;
    brain: TBrain;
  end;

var
  p: TPerson;
begin
  p.brain.DoThis;
  p.physics.x += 1;
end.

Regards,
	Ryan Joseph