[fpc-devel] Inrerface delegation by class-type property: which way to go?
sergei_gorelkin at mail.ru
Fri Dec 4 09:52:54 CET 2009
I tried to familiarize myself with the issues which must be resolved in order to get the interface
delegation by class-type properties fixed.
It appears that the there are at least two ways to go: do it exactly like in Delphi, or do it
another way :-)
Delphi way is more or less described in this attachment:
In case when an interface is delegated by class-type property, it uses specialized versions of
wrapper code that call the interface getter (or read the field value). Since FPC generates interface
wrappers at CPU-specific level in FPC, implementing it the same way seems to be quite painful (we
actually need 3 more versions of tcg.g_intf_wrapper() code, multiplied by number of supported CPUs).
Also, with this approach every call to a method of delegated interface goes through the getter,
which has effect on performance if the getter is a function.
Alternative approach could look this way:
- extend TInterfaceEntry enumeration with 3 more members, something like etFieldValueClass,
- fix the compiler to generate interface entries of those types when necessary;
- modify getinterfacebyentry() function: when the interface entry has one of abovementioned types,
it treats its result as a class and jumps to its GetInterface method.
BUT, the problem with alternative approach is that it isn't clear what should happen when a class
with delegated interfaces is typecasted to a delegated interface. A pointer to the interface can not
be obtained by offsetting the instance pointer by constant amount (with Delphi approach, it can,
because pointer to delegated interface is stored in the instance just like a regular interface).
We'll have to generate the code which reads the field (or calls the getter) and offsets the result.
So, what would be other's opinions on this?
More information about the fpc-devel