[fpc-devel] Status report for "class helpers"

[Hans-Peter Diettrich]

Sven Barth schrieb:

> Sorry, I don't understand what you want to tell here.

Sorry2, I'll retry.

> I personally expect a class helper that is defined inside a private 
> section of a class not to be available in another unit like I can't 
> access a field or another type defined in there as well.

Delphi allows for *at most* one active class helper, determined by the 
unit search order, just like every other ambiguous identifier is 
resolved. If you don't want an class helper used in other units, simply 
move it to the implementation section.

Hiding an class helper in a private section of a class IMO is not the 
right way, and the result may be compiler specific.


> If you want to have a class helper available in a derived class there is 
> only one way to do this:
[...]

Okay, now I understand the use of one ancestor, but still not the use of 
a list of ancestors.


>> 3) What about derived classes? Since derived classes are compiled
>> independently, they never will use a reintroduced method in an class
>> helper.
>>
> 
> This is correct. The following does not work in Delphi:
> 
> ==== source begin ====
> type
>   TStringsHelper = class helper for TStrings
>     procedure Test;
>   end;
> 
> var
>   s: TStringList;
> begin
>   s.Test; // this won't work
>   TStrings(s).Test // but this does
> end;
> ==== source end ====

This looks very much like my #4.

>> 4) When class helpers are evaluated at compile time, according to the
>> static object types (like properties are), then they could be handled
>> just like the well known typecast hack:
>>
>> type TMyFoo = class(TFoo)
>> <helper methods>
>> end;
>>
>> with following casts of every TFoo reference into TMyFoo.
>> But TFoo derived types must be handled in the same way, so that I see no
>> way around an extended search inside the TFoo STB.
>>
> 
> Technically class helpers ARE classes that derive from the extended 
> class (here: TFoo). But there are no casts of TFoo references. When 
> searching for a symbol in a class the last class helper in scope for 
> that class is searched first and then the symbol is searched in the 
> class itself.

Then one possible implementation could hide the extended class (TFoo), 
and use the helper class STB instead. This were the implementation of an 
implicit type cast. The symtable stack has to be built or modified 
accordingly, so that searching continues in the proper class ancestors.


>> 5) What's the meaning of the "ancestor list"? IMO interfaces cannot be
>> added by an class helper, and multiple inheritance is quite unlikely.
>> Will the ancestor list allow to override interface *implementations*?
> 
> I don't know how you come to interfaces now.

This is the normal use of a *list* of ancestors. The first ancestor 
denotes the parent class, all others denote interfaces.

> But basically from the 
> outside class helpers seem to support multiple inheritance, but 
> technically they don't. It works like this:
> 
> * the extended class is the real parent of the class helper class
> * if the class helper has a parent ( e.g. class helper(TFooHelper) for 
> TFoo ) this parent is referenced in a mostly unimportant "helperparent" 
> field of tobjectdef and only used when searching for a symbol.
> At the end the pseudo parent of a class helper tells the compiler to 
> search the symbol table of that class helper as well.

See above.

I'd push the extended class onto the symtable stack, then the class 
helper parents, and finally the class helper itself, and use that stack 
whenever a reference to a class with a helper class is encounterd.

DoDi