Discussion:
Attributes
(too old to reply)
Mattias Gaertner
2016-11-22 12:16:31 UTC
Permalink
Raw Message
Hi,

What is the current state of Delphi attributes in FPC?

Mattias
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Sven Barth
2016-11-22 13:27:28 UTC
Permalink
Raw Message
Post by Mattias Gaertner
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
Maciej Izak
2016-11-22 19:48:09 UTC
Permalink
Raw Message
Post by 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.
--
Best regards,
Maciej Izak
Jonas Maebe
2016-11-22 20:03:20 UTC
Permalink
Raw Message
Post by Maciej Izak
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!).
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

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Maciej Izak
2016-11-22 20:46:08 UTC
Permalink
Raw Message
Post by Jonas Maebe
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.
Post by Jonas Maebe
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
Jonas Maebe
2016-11-22 20:56:47 UTC
Permalink
Raw Message
Post by Maciej Izak
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.
The FPC syntax for procedure attributes is also available in
Delphi-mode, but if the modeswitch is there that's fine.
Post by Maciej Izak
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.
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Florian Klämpfl
2016-11-22 20:09:50 UTC
Permalink
Raw Message
Branch is waiting almost 3 years (sic!). Joost branch should be part of NewPascal much much sooner
Well, Joost has write permissions on FPC trunk, I think he has himself the opinion that the branch
is not ready for merging yet.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Loading...