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

[Hans-Peter Diettrich]

Paul Ishenin schrieb:

> For some reason the visibility is completely ignored here. I can add a 
> class helper to the strict private or even move it to another unit - it 
> is always visible.

IMO class helper methods always should become visible as part of the 
class, regardless of where they are declared.

 From the Delphi wiki:

"You can define and associate multiple helpers with a single type. 
However, only zero or one helper applies in any specific location in 
source code. The helper defined in the nearest scope will apply. Class 
or record helper scope is determined in the normal Delphi fashion (for 
example, right to left in the unit's uses clause)."

I.e. a single Helper reference (field) in the class definition is 
sufficient. This field cannot be persistent, instead it has to be 
initialized for every use case: whenever a helper is found in the 
compiled unit, or in one of its used units, it overwrites the Helper 
reference. Adding the helper elements to the class STB is not a valid 
solution, because another helper can become active at any time, during 
compilation.

The ancestors of the Helper class must be searched as well.


Also:

"Note that the class helper function MyFunc is called, because the class 
helper takes precedence over the actual class type."

That's bad, because this disallows to treat the helper like an ancestor, 
accessible in all derived classes :-(

Interesting questions:

1) Unit A defines an class helper for TFoo, then uses in the 
implementation section unit B, which also defines an helper for TFoo. 
According to the above rules the helper in A should become inaccessible 
and useless then.

2) Similarly multiple class helpers can be defined in the implementation 
section, which are used in the immediately following code, until the 
next helper declaration.

3) What about derived classes? Since derived classes are compiled 
independently, they never will use a reintroduced method in an class helper.

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.

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*?

DoDi