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

[Sven Barth]

On 29.01.2011 17:35, Paul Ishenin wrote:
> 29.01.2011 19:25, Sven Barth wrote:
>> 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.
> http://wiki.freepascal.org/delphi_language_features_which_fpc_does_not_have
> http://wiki.freepascal.org/FPC_New_Features_Trunk

Ok, thanks.

>> * 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)
> "If a class helper has a constructor the first statement in that
> constructor must be a call to the parameterless constructor." I think
> this is a copy-paste from some delphi .net or c# help where
> "parameterless constructor" has some special meaning.
>

Could be.

>> Regarding the algorithm I use to find the last available class helper
>> (this is implemented in
>> compiler/symtable.pas/search_last_objectpascal_classhelper):
>> 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)
> Maybe to speedup the search we can mark the symtable with a flag that if
> it contains a class helper? Other flags can come in future - like has
> type definitions - to speedup type searches.
>
>> 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.
> objfpc also allows final methods and sealed classes so it needs class
> helpers too. Better to allow them for all modes which support classes I
> think.
>

I didn't say that ObjFPC should not be able to use class helpers. I only 
wanted to mention the possibility to make the search for class helpers 
optional in that mode. But your suggestion regarding a flag might make 
this idea obsolete.

> Don't forget about record helpers. And I also noticed that in delphi
> class helpers and record helpers are synonims so you can define a class
> helper for a record and a record helper for a class - I think FPC should
> be more restrictive here.

At first I forgot them, but currently I think that I'll only finish 
class helpers for now as record helpers might prove a bit more complex: 
In normal classes most problems are taken care of because the extended 
class is the real parent of the class helper class. I don't have that 
inheritance in records though, so here one must approach that differently.

But I agree that FPC should be more strict regarding the separation of 
class helper <-> record helper.

Regards,
Sven