2016-11-22 21:03 GMT+01:00 Jonas Maebe <jonas.ma...@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
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
