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

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

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

2013/2/10 Sven Barth :

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

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

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

Maciej Izak wrote

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.

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.

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

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

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

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

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

AFAIK FPC doesn't support lambdas (yet?)

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

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

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