[fpc-devel] (class) helper questions

Paul Ishenin ip at kmiac.ru
Wed Mar 9 02:17:55 CET 2011


08.03.2011 15:24, Sven Barth wrote:

> 1. As I'm going to implement record helpers in the next time I've
> noticed that I need the modeswitch for advanced records only for
> declaring such a record.
> So how should I proceed regarding record helpers: Should the declaration
> of record helpers be restricted to that mode switch or should I allow it
> always?

They should be restricted as advanced records.

> 2. I've done some tests regardings generics in Delphi XE and have found
> out, that the following example does not compile there:
>
> === source begin ===
> TFoo<T> = class
> Field: T;
> end;
>
> TFooInteger = TFoo<Integer>;
>
> TFooHelper = class helper for TFooInteger
> end;
> === source end ===
>
> The compiler complains here that TFoo<T> is not yet completely defined.
> If I introduce an alias it does not work either, but if I subclass from
> TFooInteger and extend that class it does work (maybe the declaration of
> TFooInteger is treated like an alias in Delphi?).
> In FPC the above example currently compiles (there was no change needed
> for that). While I might file a bug report at Embarcadero, I'd like to
> know what your opinion regarding the correct behavior is.

I think this is a bug in XE.

> 3. Virtual methods and class helpers are another topic where a question
> is left. For correctly checking "override", etc. for helpers in mode
> Delphi I'm leaving the flags for virtual, etc. in the procdef although
> they should be ignored at the end. But the compiler checks them in some
> parts to do some special things for virtual methods (VMT, debug
> information, special code generation in the backends).
> The first two are solved rather easy, but should I introduce a check for
> helpers in the backends (calling "is_objectpascal_helper" for the owner
> of the procdef of the symbol) or should I introduce a "ignorevirtual"
> flag? I personally don't want the special virtual code to be generated
> for class helper methods, because it's unnecessary.

Don't generate it for class helpers using "is_objectpascal_helper".

> 4. The syntax that was introduced by Borland is not very pascalish in my
> opinion. So I'd like to change the syntax for mode ObjFPC a bit (sadly
> this won't simplify the parser anymore because of the Delphi
> compatibility).
>
> Delphi syntax:
>
> TypeIdentifier = class|record helper(ParentHelper) for ExtendedType
>
> Proposed FPC syntax:
>
> TypeIdentifier = helper(ParentHelper) for class|record ExtendedType
>
> What do you think? Maybe also the "class|record" part can be left out,
> because this part is not saved in the objectdef and can be determined by
> the compiler automatically.

I always think that if there is no need to create an incompatibility - 
better to not create it. But my ideas often does not get support of 
other FPC developers.


If you completed the class helpers syntax - then maybe to merge them 
into the trunk? Record helpers can be merged independently.

Best regards,
Paul Ishenin




More information about the fpc-devel mailing list