[fpc-devel] (class) helper questions

[Sven Barth]

Am 09.03.2011 02:17, schrieb Paul Ishenin:
> 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.
>

Will do.

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

Maybe the bug is that "class helper for TFoo<Integer>" doesn't work, 
because the situation really looks like they treat "TFoo<Integer>" as a 
fully defined type and thus "TFooInteger = TFoo<Integer>" is not a 
declaration (like in ObjFPC "TFooInteger = specialize TFoo<Integer>"), 
but a simple alias.

But I'd definitely say that there's a bug involved.

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

Ok, just thought I'd ask before I introduce that call in the backend.

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

I personally came to the conclusion that if I can try to improve the 
syntax in mode ObjFPC, I'll do it. I see no need anymore to keep modes 
Delphi and ObjFPC completely (!) compatible as already big differences 
like the generics are there.

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

Does it matter that I already implemented some parts for preparation of 
record helpers?

Regards,
Sven