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

Paul Ishenin webpirat at mail.ru
Sat Jan 29 17:35:34 CET 2011


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

> 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.

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.

Best regards,
Paul Ishenin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110129/b19ac8ff/attachment.html>


More information about the fpc-devel mailing list