Discussion:
[fpc-devel] State of extended RTTI
Maciej Izak
2013-02-10 13:19:41 UTC
Permalink
Hi,

What is the state of Extended RTTI (like in Delphi 2010 and up)?

You can read in the comment by Sven

"One of the developers has started to implement class attributes and
I’m rather sure that the enhanced RTTI will come sooner or later as
well"
http://www.deltics.co.nz/blog/?p=1129

How's he doing?

HNB
Sven Barth
2013-02-10 18:46:39 UTC
Permalink
Post by Maciej Izak
Hi,
What is the state of Extended RTTI (like in Delphi 2010 and up)?
You can read in the comment by Sven
"One of the developers has started to implement class attributes and
I’m rather sure that the enhanced RTTI will come sooner or later as
well"
http://www.deltics.co.nz/blog/?p=1129
How's he doing?
Class attributes is still being worked on in a branch (by Joost). I
personally plan to work on generics the next time (fixing bugs and
adding support for generic methods). After that I plan to tackle
extended RTTI if no one implements it before me.

Regards,
Sven
Maciej Izak
2013-02-18 17:04:26 UTC
Permalink
Can I help?

Info about good implementation of TValue -
http://www.cromis.net/blog/2013/02/tanyvalue-an-attempt-to-make-the-best-variable-data-container/
Has FPC some equivalent of invoke from rtti.pas (dynamically invoking
a methods and procedures/functions)? If not - I have my own basic
implementation (for stdcall, register and cdecl) based on PascalScript
calling engine.

Regards,
HNB
Post by Sven Barth
Post by Maciej Izak
Hi,
What is the state of Extended RTTI (like in Delphi 2010 and up)?
You can read in the comment by Sven
"One of the developers has started to implement class attributes and
I’m rather sure that the enhanced RTTI will come sooner or later as
well"
http://www.deltics.co.nz/blog/?p=1129
How's he doing?
Class attributes is still being worked on in a branch (by Joost). I
personally plan to work on generics the next time (fixing bugs and adding
support for generic methods). After that I plan to tackle extended RTTI if
no one implements it before me.
Regards,
Sven
_______________________________________________
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Boian Mitov
2013-02-18 19:30:46 UTC
Permalink
Hi All,

We have developed an advanced RTTI API that replaces the Embarcadero RTTI
API and provides much more powerful and easy to use when accessing the RTTI.
We developed it as we ware running into huge number of issues and bugs when
trying to use the Embarcadero implementation, and we needed stable, robust
and very easy to use implementation, since we have started to rely very
heavily on the new RTTI in our development. It also offers additional
functionalities not currently available in the Embarcadero extended RTTI, as
well as we are doing some work around for critical bugs in the Delphi RTTI
unit.
If there is interest in adding extended RTTI support in FPC, i am willing to
donate the API, and its implementation to the effort if it is deemed a good
fit.
Who is working on the RTTI at the moment? I can send him/her/them the RTTI
unit for evaluation.

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Maciej Izak
Sent: Monday, February 18, 2013 9:04 AM
To: FPC developers' list
Subject: Re: [fpc-devel] State of extended RTTI

Can I help?

Info about good implementation of TValue -
http://www.cromis.net/blog/2013/02/tanyvalue-an-attempt-to-make-the-best-variable-data-container/
Has FPC some equivalent of invoke from rtti.pas (dynamically invoking
a methods and procedures/functions)? If not - I have my own basic
implementation (for stdcall, register and cdecl) based on PascalScript
calling engine.

Regards,
HNB
Post by Sven Barth
Post by Maciej Izak
Hi,
What is the state of Extended RTTI (like in Delphi 2010 and up)?
You can read in the comment by Sven
"One of the developers has started to implement class attributes and
I’m rather sure that the enhanced RTTI will come sooner or later as
well"
http://www.deltics.co.nz/blog/?p=1129
How's he doing?
Class attributes is still being worked on in a branch (by Joost). I
personally plan to work on generics the next time (fixing bugs and adding
support for generic methods). After that I plan to tackle extended RTTI if
no one implements it before me.
Regards,
Sven
_______________________________________________
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Sven Barth
2013-02-18 19:37:52 UTC
Permalink
Post by Boian Mitov
Hi All,
We have developed an advanced RTTI API that replaces the Embarcadero
RTTI API and provides much more powerful and easy to use when accessing
the RTTI.
We developed it as we ware running into huge number of issues and bugs
when trying to use the Embarcadero implementation, and we needed stable,
robust and very easy to use implementation, since we have started to
rely very heavily on the new RTTI in our development. It also offers
additional functionalities not currently available in the Embarcadero
extended RTTI, as well as we are doing some work around for critical
bugs in the Delphi RTTI unit.
If there is interest in adding extended RTTI support in FPC, i am
willing to donate the API, and its implementation to the effort if it is
deemed a good fit.
Who is working on the RTTI at the moment? I can send him/her/them the
RTTI unit for evaluation.
No one is currently working on the RTTI itself. Attributes are currently
being worked on, but without support through the RTTI unit (procedural
access is provided through the TypInfo unit).

How compatible to Delphi's API is your API? If it is not compatible,
then it would not be of much use to us. Please note that we would in any
case only use the API itself, as we might not implement the binary
layout of the RTTI necessarily the same as Delphi did.

Regards,
Sven
Boian Mitov
2013-02-18 19:49:53 UTC
Permalink
Hi Sven,

It is an abstraction API that on the low side is 100% compatible with the
Delphi API, as it uses it to access the information, but on the user side
presents extremely easy to use API. It is probably better than anything
available in the world at the moment, and light years ahead of both the
Microsoft .NET RTTI API and the Embarcadero RTTI API. Being abstraction
layer it also can be hooked on anything you have on the back end without
breaking the code.

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Sven Barth
Sent: Monday, February 18, 2013 11:37 AM
To: fpc-***@lists.freepascal.org
Subject: Re: [fpc-devel] State of extended RTTI

On 18.02.2013 20:30, Boian Mitov wrote:

How compatible to Delphi's API is your API? If it is not compatible,
then it would not be of much use to us. Please note that we would in any
case only use the API itself, as we might not implement the binary
layout of the RTTI necessarily the same as Delphi did.
Sven Barth
2013-02-18 20:01:28 UTC
Permalink
Post by Boian Mitov
Hi Sven,
It is an abstraction API that on the low side is 100% compatible with
the Delphi API, as it uses it to access the information, but on the user
side presents extremely easy to use API. It is probably better than
anything available in the world at the moment, and light years ahead of
both the Microsoft .NET RTTI API and the Embarcadero RTTI API. Being
abstraction layer it also can be hooked on anything you have on the back
end without breaking the code.
In that case it might be a viable addition to the Delphi compatible API.
If we'd use your API we could also adjust its implementation in such a
way that it directly uses FPC's yet-to-be-implemented RTTI data (which
would improve performance).

If you want you could send me a version of your unit so that I can take
a look at it.

Just in case: If we should integrate the API as part of the RTL would
you be willing to publish it under our modified-LGPL license? If you
prefer a different license we could provide your API either as an
additional package bundled with FPC's distribution or provided through
the FPPKG system. [of course only once we've implemented extended RTTI
at all ;) ]

Regards,
Sven
Boian Mitov
2013-02-18 20:02:33 UTC
Permalink
As example this enumerates all attributes of certain type for any public or
published member (function, field, or property) for a component:


for LMember in TRTRtti.GetType( Component.ClassType() ).GetMembers(
[mvPublic, mvPublished] ) do
for LAtrribute in LMember.GetAttributes( TMyCustomAttributeType, True ) do

You can see how much can be achieved with almost no code :-D and this is
just the tip of the iceberg ;-) . It supports filtering with lambdas, and in
general is designed in the principles of functional programming, so you can
as example filter like this:

AAttributes := TRTRtti.GetType(
Component.ClassType() ).GetCustomAttributes(
TVLCommonFilterHostedPreviewAttribute, True );
for AAttribute in AAttributes do
if( AAttribute is TLPComponentEditorAttribute ) then
begin
AAttrItem := GComponentEditorAttributeList.Find(
function( AItem : IComponentEditorAttributeItem ) :
Boolean
var
AAttributes : IRTAttributes;
AAttributeClass : TCustomAttributeClass;

begin
AAttributeClass :=
AItem.GetInstance().AttributeClass;
AAttributes := TRTRtti.GetType(
Component.ClassType() ).GetCustomAttributes( TLPSuppressAttributeAttribute,
True );
if( AAttributes.Find(
function ( ASupressAttribute :
TCustomAttribute ) : Boolean
begin
Result := ( AAttributeClass =
TLPSuppressAttributeAttribute( ASupressAttribute ).Attribute );
end
) <> NIL ) then
Exit( False );

Result := ( AAttribute is AAttributeClass );
end
);

Exit( AAttrItem.GetInstance().ComponentEditor.Create( Component,
Designer ));
end;

This actually is a real piece of code from a place we use the new RTTI ;-)

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Boian Mitov
Sent: Monday, February 18, 2013 11:49 AM
To: FPC developers' list
Subject: Re: [fpc-devel] State of extended RTTI

Hi Sven,

It is an abstraction API that on the low side is 100% compatible with the
Delphi API, as it uses it to access the information, but on the user side
presents extremely easy to use API. It is probably better than anything
available in the world at the moment, and light years ahead of both the
Microsoft .NET RTTI API and the Embarcadero RTTI API. Being abstraction
layer it also can be hooked on anything you have on the back end without
breaking the code.

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Sven Barth
Sent: Monday, February 18, 2013 11:37 AM
To: fpc-***@lists.freepascal.org
Subject: Re: [fpc-devel] State of extended RTTI

On 18.02.2013 20:30, Boian Mitov wrote:

How compatible to Delphi's API is your API? If it is not compatible,
then it would not be of much use to us. Please note that we would in any
case only use the API itself, as we might not implement the binary
layout of the RTTI necessarily the same as Delphi did.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Kostas Michalopoulos
2013-02-19 13:36:10 UTC
Permalink
AFAIK FPC doesn't support lambdas (yet?)
Post by Boian Mitov
As example this enumerates all attributes of certain type for any public
for LMember in TRTRtti.GetType( Component.ClassType() ).GetMembers(
[mvPublic, mvPublished] ) do
for LAtrribute in LMember.GetAttributes( TMyCustomAttributeType, True ) do
You can see how much can be achieved with almost no code :-D and this is
just the tip of the iceberg ;-) . It supports filtering with lambdas, and
in general is designed in the principles of functional programming, so you
AAttributes := TRTRtti.GetType( Component.ClassType()
).GetCustomAttributes( TVLCommonFilterHostedPreviewAt**tribute, True );
for AAttribute in AAttributes do
if( AAttribute is TLPComponentEditorAttribute ) then
begin
AAttrItem := GComponentEditorAttributeList.**Find(
Boolean
var
AAttributes : IRTAttributes;
AAttributeClass : TCustomAttributeClass;
begin
AAttributeClass := AItem.GetInstance().**
AttributeClass;
AAttributes := TRTRtti.GetType(
Component.ClassType() ).GetCustomAttributes( TLPSuppressAttributeAttribute,
True );
if( AAttributes.Find(
TCustomAttribute ) : Boolean
begin
Result := ( AAttributeClass =
TLPSuppressAttributeAttribute( ASupressAttribute ).Attribute );
end
) <> NIL ) then
Exit( False );
Result := ( AAttribute is AAttributeClass );
end
);
Exit( AAttrItem.GetInstance().**ComponentEditor.Create( Component,
Designer ));
end;
This actually is a real piece of code from a place we use the new RTTI ;-)
With best regards,
Boian Mitov
------------------------------**-------------------------
Mitov Software
www.mitov.com
------------------------------**-------------------------
-----Original Message----- From: Boian Mitov
Sent: Monday, February 18, 2013 11:49 AM
To: FPC developers' list
Subject: Re: [fpc-devel] State of extended RTTI
Hi Sven,
It is an abstraction API that on the low side is 100% compatible with the
Delphi API, as it uses it to access the information, but on the user side
presents extremely easy to use API. It is probably better than anything
available in the world at the moment, and light years ahead of both the
Microsoft .NET RTTI API and the Embarcadero RTTI API. Being abstraction
layer it also can be hooked on anything you have on the back end without
breaking the code.
With best regards,
Boian Mitov
------------------------------**-------------------------
Mitov Software
www.mitov.com
------------------------------**-------------------------
-----Original Message----- From: Sven Barth
Sent: Monday, February 18, 2013 11:37 AM
Subject: Re: [fpc-devel] State of extended RTTI
How compatible to Delphi's API is your API? If it is not compatible,
then it would not be of much use to us. Please note that we would in any
case only use the API itself, as we might not implement the binary
layout of the RTTI necessarily the same as Delphi did.
______________________________**_________________
http://lists.freepascal.org/**mailman/listinfo/fpc-devel<http://lists.freepascal.org/mailman/listinfo/fpc-devel>
______________________________**_________________
http://lists.freepascal.org/**mailman/listinfo/fpc-devel<http://lists.freepascal.org/mailman/listinfo/fpc-devel>
Boian Mitov
2013-02-19 17:05:02 UTC
Permalink
I think they (FPC) have added their own implementation. Haven’t looked in more details, but saw some code posted, and I think they had a different implementation than Emb., using the lambda keyword.
In any case at some point it will have to be adopted one way or another, as it helps tremendously in reducing and improving the code. We decided to ditch support for any version of Delphi older than XE2 mainly because of the enormous power of the Lambdas, and the bugs in the XE implementation (a lot of internal compiler errors).

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------


From: Kostas Michalopoulos
Sent: Tuesday, February 19, 2013 5:36 AM
To: FPC developers' list
Subject: Re: [fpc-devel] State of extended RTTI

AFAIK FPC doesn't support lambdas (yet?)
Sven Barth
2013-02-19 21:18:37 UTC
Permalink
I think they (FPC) have added their own implementation. Haven’t looked
in more details, but saw some code posted, and I think they had a
different implementation than Emb., using the lambda keyword.
In any case at some point it will have to be adopted one way or another,
as it helps tremendously in reducing and improving the code. We decided
to ditch support for any version of Delphi older than XE2 mainly because
of the enormous power of the Lambdas, and the bugs in the XE
implementation (a lot of internal compiler errors).
No, FPC does currently not support anonymous functions (please don't
call them Lambdas... at least not with that verbose syntax ;) ). We have
a branch where an independant developer started to work on them, but
development there has stalled.
What you might have seen recently on this list was a discussion about a
potential improvement of the syntax (less verbose for simpler cases).

Regards,
Sven
Boian Mitov
2013-02-19 21:28:37 UTC
Permalink
Hi Sven,

Thank you!

I actually find "anonymous method" more verbose than "lambda" in a sentence
:-D .
Then the FPC is really way behind almost any other language :-( . Even C++
added native anonymous methods in C++11, and other languages have had them
for many years :-( .
I can't even imagine my development without them in Delphi any more, I mean
they really revolutionized my code, and allowed me to do things I have never
imagined before. Together with Attributes, and the new RTTI this is the
biggest revolution in Delphi, and transforms it into totally different
language. Now I can get something done with 4-5 lines of code which
otherwise would have required hundreds of lines and declaration of a whole
bunch of additional support classes and code. I mean this is a whole new
ballgame altogether! It is even bigger than the Object Oriented programming
was when it was introduced!

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Sven Barth
Sent: Tuesday, February 19, 2013 1:18 PM
To: fpc-***@lists.freepascal.org
Subject: Re: [fpc-devel] State of extended RTTI

On 19.02.2013 18:05, Boian Mitov wrote:

No, FPC does currently not support anonymous functions (please don't
call them Lambdas... at least not with that verbose syntax ;) ). We have
a branch where an independant developer started to work on them, but
development there has stalled.
What you might have seen recently on this list was a discussion about a
potential improvement of the syntax (less verbose for simpler cases).

Regards,
Sven

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

Leonardo M. Ramé
2013-02-18 19:39:07 UTC
Permalink
Post by Sven Barth
________________________________
Sent: Monday, February 18, 2013 4:30 PM
Subject: Re: [fpc-devel] State of extended RTTI
   Hi All,
We have developed an advanced RTTI API that replaces the Embarcadero RTTI API and provides much more powerful and easy to use when accessing the RTTI.
We developed it as we ware running into huge number of issues and bugs when trying to use the Embarcadero implementation, and we needed stable, robust and very easy to use implementation, since we have started to rely very heavily on the new RTTI in our development. It also offers additional functionalities not currently available in the Embarcadero extended RTTI, as well as we are doing some work around for critical bugs in the Delphi RTTI unit.
If there is interest in adding extended RTTI support in FPC, i am willing to donate the API, and its implementation to the effort if it is deemed a good fit.
Who is working on the RTTI at the moment? I can send him/her/them the RTTI unit for evaluation.
With best regards,
Boian Mitov
Hi Boian, did you have to modify/patch the compiler, or it is implemented as a set of classes?.


Leonardo M. Ramé
http://leonardorame.blogspot.com
Boian Mitov
2013-02-18 19:51:16 UTC
Permalink
Hi Leonardo,

At the moment we are only replacing some of the buggy parts of the catching
in the Emb. RTTI. We are also working to get it to perform faster than the
Delphi RTTI by implementing our own caching mechanisms.

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Leonardo M. Ramé
Sent: Monday, February 18, 2013 11:39 AM
To: FPC developers' list
Subject: Re: [fpc-devel] State of extended RTTI

Hi Boian, did you have to modify/patch the compiler, or it is implemented as
a set of classes?.


Leonardo M. Ramé
http://leonardorame.blogspot.com
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Sven Barth
2013-02-18 19:46:52 UTC
Permalink
Post by Maciej Izak
Can I help?
The generation of the extended RTTI data is currently missing which
needs corresponding knowledge in the compiler. And I'm also waiting for
the finishing of the attributes implementation which will pave some way
for the extended RTTI data. Also Joost (who implements the attributes)
stated that he's also working on a primitive RTTI unit, so that needs to
be checked first. Additionally support for generic methods needs to be
added (this is on my own near term todo list).

After that ground work you would principially be free to implement the
RTTI unit.
Post by Maciej Izak
Info about good implementation of TValue -
http://www.cromis.net/blog/2013/02/tanyvalue-an-attempt-to-make-the-best-variable-data-container/
Please note that the interface needs to be implemented in a way
compatible to Delphi's RTTI.TValue.
Post by Maciej Izak
Has FPC some equivalent of invoke from rtti.pas (dynamically invoking
a methods and procedures/functions)? If not - I have my own basic
implementation (for stdcall, register and cdecl) based on PascalScript
calling engine.
We currently don't have an Invoke function. Please note that we also
have additional calling conventions (oldfpccall, cppdecl) and that the
conventions used on other platforms (especially other CPUs) are different.

Regards,
Sven
Loading...