> On Feb 15, 2021, at 11:41 PM, Sven Barth via fpc-pascal
> <fpc-pascal@lists.freepascal.org> wrote:
>
> Again, the point of the interface would be to control which methods and
> properties of the delegated type would be available. Also it would allow for
> seamless integration with the RTTI as it's possible to query the implemented
> interface of a class and to retrieve a reference to it, thus it would be
> possible to access this at runtime as well.
>
> The compiler will generate a VMT for the interface with method thunks that
> adjust the Self pointer so that it works correctly. The GetInterfaceByEntry
> function uses this static data to generate an adjusted Self value that
> callers can use.
As far as the "default implements property" is concerned we don't actually
need, or even want to utilize the interfaces themselves. The idea of leveraging
the interface syntax for exporting method names is one thing but if we actually
have to use the interfaces internally then we open a whole can of worms in
terms of performance. Class instantiation may be taking on some significant
baggage now also as the compiler sets up these interface VMT tables, even if
the user never needs or wants them.
For example this code should be a compile time indirection instead of a hidden
interface cast, right? The method forwarding syntax which works by modifying
the VMT can hopefully be done at compile time for the default property also.
type
ICircle = interface
procedure Draw;
end;
type
TCircle = record
procedure Draw;
end;
type
TMyShape = class(ICircle)
private
FCircle: TCircle;
public
property Circle: TCircle read FCircle implements ICircle; default;
end;
var
shape: TMyShape;
begin
shape := TMyShape.Create;
{ calls shape.FCircle.Draw instead of ICircle(shape).Draw }
shape.Draw;
end.
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
