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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
