[fpc-devel] Attributes

[Maciej Izak]

2016-11-22 21:03 GMT+01:00 Jonas Maebe <jonas.maebe at elis.ugent.be>:

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

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.


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

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.

-- 
Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20161122/0094f915/attachment.html>