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

Sven Barth pascaldragon at googlemail.com
Sat Jan 29 13:25:15 CET 2011

Hello together!

I've decided to provide a little status report on the "class helper" 
feature that I'm currently implementing.

I found the time to put up a first version of a wiki page: 

Does someone know a good place to link this page from? Maybe something 
where other language/compiler features are referenced from or can be 
linked to in the future.

And yes, I plan to extend the "Code examples" list further. :D

Now what is my current status?
* class helper syntax is supported (including inheritance - which is a 
pseudo inheritance internally)
* calling methods that are provided by a class helper works
* only the last available class helper is used (regarding the search 
algorithm see below)
* enumerators provided by class helpers are used
* overloading methods of the extended class with the ones provided by 
the class helper does NOT work currently (I need to investigate how 
"overload" works at all ^^)
* in mode Delphi "override" and "virtual" are ignored (they are 
disallowed for mode ObjFPC), but as I remove their corresponding flags I 
might have a problem with the following example that compiles in newer 
Delphis (at least Delphi 2007 does not compile this, because of an 
incorrect implementation in the compiler):

==== source begin ====
   THelper1 = class helper for TObject
     procedure Foo; virtual;

   THelper2 = class helper(THelper1) for TObject
     procedure Foo; override;
==== source end ====

* I have experienced one time that Delphi chokes on properties. I'll 
need to investigate that further (one can define them, but Delphi does 
not seem to find them)
* I have yet to test whether the restriction "Create must be first 
statement in constructors" holds true (I've found a code sample that 
suggests its not true)
* I have yet to read about "class constructors" and whether they can be 
used (and how)

This basically sums up my status.

Regarding the algorithm I use to find the last available class helper 
(this is implemented in 
Delphi uses the last class helper that is available in the current scope 
for method resolution (and the "parents" of that class helper). For this 
I walk the symtable stack and search for a def where 
is_objectpascal_classhelper returns "true". This can potentially lead to 
a bad runtime behavior if a project does not use any class helpers, but 
includes many units (the compiler is a good example of that).
Do you (especially @Devs) think that this is a sufficient approach or 
should this be done another way? (Note: I have not yet profiled 
compiling the compiler once with that search enabled and once without)

Perhaps searching for class helpers should be made dependent on a 
modeswitch? E.g. "useclasshelpers"
That might lead to the potentially confusing behavior that a class 
helper is not even found in its own unit though, although I think that 
this would be a consequent behavior (the switch needs to be documented 
good enough though ^^).
This switch could be enabled by default in mode Delphi.

Also as Delphi searches a class helper based on the last available class 
helper instead of the last available method as Objective C categories 
do, I think that I don't need to generate that static symbols (done by 
create_class_helper_for_procdef in symdef.pas). Any objections for 
disabling that for Object Pascal class helpers again?

Two other questions regarding compiler internals:
Do I need to consider something regarding WPO? Or is all that done 
automatically by the compiler already (e.g. by me referencing the symbol 
of a class helper method)?

What is the difference between the "Message*" and "CGMessage*" 
procedures? Or asked differently: when should I use which?


More information about the fpc-devel mailing list