Hi,

What is the current state of Delphi attributes in FPC?

Mattias

"Mattias Gaertner" wrote

Hi, What is the current state of Delphi attributes in FPC?

There is still Joost's branch that's waiting to be merged, but even then this would only contain class attributes.

Regards,
Sven

2016-11-22 14:27 GMT+01:00 Sven Barth :

There is still Joost's branch that's waiting to be merged, but even then this would only contain class attributes.

I have checked Joost implementation and generally seems ok (logically most important part for me about "when" and "how" is called constructor for attributes is alright).

Branch is waiting almost 3 years (sic!). Joost branch should be part of NewPascal much much sooner than official FPC trunk, anyway I have question:

Eventually rework for this branch has any sense? I am asking because I need to prepare some work on this branch for NewPascal purposes. I prefer "less" work but if I can somehow help to "speed-up" FPC-trunk integration then I prefer to rework this branch in similar way like for management operators.

That's because
a) it breaks the syntax for procedure attributes that has existed since the beginning in FPC in case such an attribute comes right after a procedure declaration (like procedure test; [public, alias: 'abc'];). At the very least the attributes need an extra modeswitch to activate them in order not to potentially break existing code by default. b) the generated type info is Delphi-incompatible (TAttributeData vs TAttrData, no TAttrEntry). Some people wanted it to be Delphi-compatible, other people considered this is an implementation detail and that we do not have to follow Delphi here.

Jonas

Maciej Izak wrote

Branch is waiting almost 3 years (sic!). Joost branch should be part of NewPascal much much sooner than official FPC trunk, anyway I have question:

Well, Joost has write permissions on FPC trunk, I think he has himself the opinion that the branch is not ready for merging yet.

2016-11-22 21:03 GMT+01:00 Jonas Maebe :

modeswitch prefixedattributes is implemented (and seems it works) and can be used by default in Delphi mode only, so I think this is not the problem.

Don't get my next words as attack but... I don't understand double standards. TypInfo is already incompatible, first example:

http://lists.freepascal.org/pipermail/fpc-devel/2016-March/036742.html http://bugs.freepascal.org/view.php?id=29767

I still have objections about ManagedFldCount which is in many cases buggy/problematic for existing Delphi code base and has improper naming (btw. info about all record fields in that form is useless). On the other hand I need to read "We can't accept that because is Delphi-incompatible".

TypInfo module is less important than RTTI module. In most of cases for newer code TypInfo is rarely used. At the end we can mark TAttributeData as experimental feature. Generics.Collections is also incompatible on details but i prefer to have somehow incompatible important feature than don't have that feature.

The FPC syntax for procedure attributes is also available in Delphi-mode, but if the modeswitch is there that's fine.

As I said, some people wanted it to be Delphi compatible, other people did not mind if it was not. Both categories of people were in the core team. There is nevertheless in fact a double standard here, but only in the sense of new features vs. existing features: making something Delphi-compatible when it is newly introduced does not break anything, while changing something that already exists breaks backward compatibility.

Exactly because of that reason, the discussions can be more heated when it concerns a new feature, because it is known that it is virtually impossible to change later.

Jonas