The new Delphi 2010 RTTI

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The new Delphi 2010 RTTI

tcoq
Hello,

Delphi 2010 has changed the RTTI mechanism, and it is said to be much
more usable than the previous one.
(see here for example: http://www.malcolmgroves.com/blog/?p=476)

Some interesting tools are using this new approach, like DelphiOnRails:
http://code.google.com/p/delphionrails/

Currently, the FPC doesn't implement this new mechanism (See Jonas'
answer to my previous post, badly sent :-( ).
But it might be possible to add this mechanism, by making patches to FPC.

Would it interest somebody to have this new functionality?

Best regards,
Thierry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Paul Ishenin-2
11.12.2010 13:13, Thierry Coq wrote:
> Delphi 2010 has changed the RTTI mechanism, and it is said to be much
> more usable than the previous one.
> (see here for example: http://www.malcolmgroves.com/blog/?p=476)
I would said extended what they had before.
> Currently, the FPC doesn't implement this new mechanism (See Jonas'
> answer to my previous post, badly sent :-( ).
> But it might be possible to add this mechanism, by making patches to FPC.
Yes.
>
> Would it interest somebody to have this new functionality?
Yes.

Best regards,
Paul Ishenin
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Michael Van Canneyt


On Sat, 11 Dec 2010, Paul Ishenin wrote:

> 11.12.2010 13:13, Thierry Coq wrote:
>> Delphi 2010 has changed the RTTI mechanism, and it is said to be much more
>> usable than the previous one.
>> (see here for example: http://www.malcolmgroves.com/blog/?p=476)
> I would said extended what they had before.

Indeed, it's an extension of what existed before.

>> Currently, the FPC doesn't implement this new mechanism (See Jonas' answer
>> to my previous post, badly sent :-( ).
>> But it might be possible to add this mechanism, by making patches to FPC.
> Yes.
>>
>> Would it interest somebody to have this new functionality?
> Yes.

I agree with Paul. The FPC team is certainly interested in having this,
but finding time to implement this is another matter.

If you want to look into it, I think Paul can help on the compiler end,
and I'm willing to help with the extra RTL functionality.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

tcoq
On 11/12/2010 11:53, Michael Van Canneyt wrote:
...
> If you want to look into it, I think Paul can help on the compiler
> end, and I'm willing to help with the extra RTL functionality.
How can I help?
I know a lot how the Delphi RTTI works, but I don't have a Delphi 2010
version (too expensive)!
I'm going to look into the specs and what are the differences with FPC's
current implementation.
I can also download a DelphiOnRails version and see how it is used in
practice.

Thierry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

tcoq
Hello,
I've started looking into Delphi 2010 RTTI scheme. For example,
superobject uses it. Delphi 2010 declares a whole new API for RTTI.
Would it be possible to reproduce the interface of this API and
implement it using the existing RTTI system in FPC? Would it be legal?

I'm investigating further.
Thierry

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Jonas Maebe-2

On 22 Dec 2010, at 15:22, Thierry Coq wrote:

> I've started looking into Delphi 2010 RTTI scheme. For example,  
> superobject uses it. Delphi 2010 declares a whole new API for RTTI.  
> Would it be possible to reproduce the interface of this API and  
> implement it using the existing RTTI system in FPC? Would it be legal?

Yes, that would be legal.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Paul Ishenin-2
In reply to this post by tcoq
22.12.2010 21:22, Thierry Coq wrote:
> Hello,
> I've started looking into Delphi 2010 RTTI scheme. For example,
> superobject uses it. Delphi 2010 declares a whole new API for RTTI.
> Would it be possible to reproduce the interface of this API and
> implement it using the existing RTTI system in FPC?
Yes, it will be possible. But there are few problems:
1. compiler does not produce required information. It already produces
more than was needed for D7 compatibility but still less than D2010.
2. new switches needs to be added to compiler to tune what kind of info
to generate in rtti
3. another thing is rtti unit. At the moment it can't be compiled in fpc
because it intensively uses extended record syntax. Good thing is I'm
currently implementing this syntax extensions in FPC. You already can
play with methods and visibility sections in records but it is still not
enough to be able to compile rtti unit.

Best regards,
Paul Ishenin
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Anthony Walter-3
Paul,

Thanks for working on adding methods and visibility to record types. Could you also look into fixing generics? That is, to allow for generic constraints and remove the redundant generic and specialize keywords. For example:

{code}

type
  TList<T> = class { ... interface code ... }  end;
  TIntegerList = class(TList<Integer>) end;
  TObjectList<T: TObject> = class(TList<T>) end;

var
  Dates: TList<TDateTime>;
  Integers: TIntegerList;
  Threads: TObjectList<TThread>; 

{code}

Note the lack of redundant generic and specialize keywords. It is obvious the type is generic by virtue of the <> angle brackets after the type identifier. Also notice the type constraint after T in the object list type declaration.

Thanks!

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Paul Ishenin-2
22.12.2010 22:13, Anthony Walter wrote:
> Thanks for working on adding methods and visibility to record types.
> Could you also look into fixing generics? That is, to allow for
> generic constraints and remove the redundant generic and specialize
> keywords.
I hope someone else will do this. At least this has low priority for me.

Best regards,
Paul Ishenin
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Dimitri Smits-2
In reply to this post by tcoq
Hi,

what is so different on this mail than the one I sent a few months ago to the fpc-devel list?

anyway, it would require some packages (bpl) language/RTE additions as well. That was where I was hanging when spare time slipped away a few months back. I started on rtti unit with help in embarcadero's online wiki. Btw, during those few weeks, I noticed the XE updates. In theory it is possible to do some AOP in Delphi XE now with TVirtualMethodInterceptor or something like that.

the unit wasn't all that useful yet (mostly interface) and probably partially obsolete due to the XE upgrade :-).

kind regards,
Dimitri Smits

----- "Thierry Coq" <[hidden email]> schreef:

> Hello,
>
> Delphi 2010 has changed the RTTI mechanism, and it is said to be much
>
> more usable than the previous one.
> (see here for example: http://www.malcolmgroves.com/blog/?p=476)
>
> Some interesting tools are using this new approach, like
> DelphiOnRails:
> http://code.google.com/p/delphionrails/
>
> Currently, the FPC doesn't implement this new mechanism (See Jonas'
> answer to my previous post, badly sent :-( ).
> But it might be possible to add this mechanism, by making patches to
> FPC.
>
> Would it interest somebody to have this new functionality?
>
> Best regards,
> Thierry
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Michael Van Canneyt


On Wed, 22 Dec 2010, Dimitri Smits wrote:

> Hi,
>
> what is so different on this mail than the one I sent a few months ago to the fpc-devel list?
>
> anyway, it would require some packages (bpl) language/RTE additions as well.

Would you care to explain why you think so ?

The 2 features have nothing to do with each other whatsoever.
You can perfectly add extended RTTI to FPC without package support.

It may be that package support (if/whenever it appears) may need to take into account
RTTI, but certainly not the other way round.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Dimitri Smits-2
In reply to this post by tcoq
Sure, but I was talking about the RTTI unit and API compatibility. (hierarchical starting point is program, then package, then unit, then type)

more pressing would be:
- list of units in program (only once, hence the packages or monolythic executable)
- list of types/vars/methods in that unit

a TClass should be able to get its unitname as well.

Your remark on the package support is invalid. The other way around IS valid as well, since the api of the rtti unit has some dependencies. If Packages are ever implemented, then the api must be corrected. Likewise, some parts of the api are made from their point of view (embarcadero's), where an executable is a package, as well as every bpl, and each add their unit-info's to the RTE on load of that "package". From there a logical hierarchy is possible, which shows a bit in the rtti unit api. It all depends on the direction of the relationship (tclass.unitname, tunitinfo.packagename, but also rtticontext.findtype('unit.type')) which makes the implementation a breeze or a bit harder.

from http://docwiki.embarcadero.com/VCL/en/RTTI.TRttiContext

  TRttiContext = record
  public
    class function Create: TRttiContext; static;
    procedure Free;
    function GetType(ATypeInfo: Pointer): TRttiType; overload;
    function GetType(AClass: TClass): TRttiType; overload;
    function GetTypes: TArray<TRttiType>;
    function FindType(const AQualifiedName: string): TRttiType;
    function GetPackages: TArray<TRttiPackage>;
  end;

where TArray<TRttiPackage> and TArray<TRttiType> is btw a generically defined => TArray<T>=array of T;

Since Delphi can have only one instance of a unit in memory (error on load otherwise regarding duplicate units), and can load/unload dll/bpl at runtime, the entire FindType method starts with the packages and the onload/onunload hooks must take into account that that array gets updated/invalidated. bidirectional dependencies are to be avoided, but here we are... make without packages => change interface, change trivialness of implementation, change rtti on types; implement packages later on => reimplement, reinstate interface, change rtti again on types (if still possible).

kind regards,
Dimitri Smits

----- "Michael Van Canneyt" <[hidden email]> schreef:

> On Wed, 22 Dec 2010, Dimitri Smits wrote:
>
> > Hi,
> >
> > what is so different on this mail than the one I sent a few months
> ago to the fpc-devel list?
> >
> > anyway, it would require some packages (bpl) language/RTE additions
> as well.
>
> Would you care to explain why you think so ?
>
> The 2 features have nothing to do with each other whatsoever.
> You can perfectly add extended RTTI to FPC without package support.
>
> It may be that package support (if/whenever it appears) may need to
> take into account
> RTTI, but certainly not the other way round.
>
> Michael.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Sven Barth-2
On 22.12.2010 17:46, Dimitri Smits wrote:
> a TClass should be able to get its unitname as well.
>

FPC already supports TClass.UnitName.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Michael Van Canneyt
In reply to this post by Dimitri Smits-2


On Wed, 22 Dec 2010, Dimitri Smits wrote:

> Sure, but I was talking about the RTTI unit and API compatibility. (hierarchical starting point is program, then package, then unit, then type)
>
> more pressing would be:
> - list of units in program (only once, hence the packages or monolythic executable)
> - list of types/vars/methods in that unit
>
> a TClass should be able to get its unitname as well.
>
> Your remark on the package support is invalid. The other way around IS
> valid as well, since the api of the rtti unit has some dependencies.  If
> Packages are ever implemented, then the api must be corrected.

So ?

Then we'll correct the API as far as needed. It's just a matter of installing
some hooks now (they'll probably be in Delphi's RTTI API anyway).
We did the same for threads, resourcestrings, variants and widestrings, after all.

Therefore, until the time someone finds a cross-platform way to implement packages,
I see no reason not to start on RTTI. They can perfectly be implented independently
or even in parallel.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
22.12.2010 21:52, Michael Van Canneyt пишет:
>
> Therefore, until the time someone finds a cross-platform way to
> implement packages, I see no reason not to start on RTTI. They can
> perfectly be implented independently
> or even in parallel.
>
Wine has ability to load windows libraries on linux. This technology
could be used to implement cross-platform packages.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Marco van de Voort
In our previous episode, [hidden email] said:
> > Therefore, until the time someone finds a cross-platform way to
> > implement packages, I see no reason not to start on RTTI. They can
> > perfectly be implented independently
> > or even in parallel.
> >
> Wine has ability to load windows libraries on linux.

.. into windows programs.

> This technology could be used to implement cross-platform packages.

Yes, run the FPC/win32 binary in Wine :-)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
23.12.2010 17:52, Marco van de Voort пишет:

> In our previous episode, [hidden email] said:
>>> Therefore, until the time someone finds a cross-platform way to
>>> implement packages, I see no reason not to start on RTTI. They can
>>> perfectly be implented independently
>>> or even in parallel.
>>>
>> Wine has ability to load windows libraries on linux.
> .. into windows programs.
>
>> This technology could be used to implement cross-platform packages.
> Yes, run the FPC/win32 binary in Wine :-)
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>

I`ve heard that some cross-platform projects use this to build
cross-platform plug-ins.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Michael Van Canneyt


On Thu, 23 Dec 2010, [hidden email] wrote:

> 23.12.2010 17:52, Marco van de Voort пишет:
>> In our previous episode, [hidden email] said:
>>>> Therefore, until the time someone finds a cross-platform way to
>>>> implement packages, I see no reason not to start on RTTI. They can
>>>> perfectly be implented independently
>>>> or even in parallel.
>>>>
>>> Wine has ability to load windows libraries on linux.
>> .. into windows programs.
>>
>>> This technology could be used to implement cross-platform packages.
>> Yes, run the FPC/win32 binary in Wine :-)
>>
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>>
>
> I`ve heard that some cross-platform projects use this to build cross-platform
> plug-ins.
It would create an unwanted dependency on wine.
For such a basic functionality, that's simply out of the question.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Sven Barth-2
In reply to this post by Alexander Shishkin
Am 23.12.2010 16:20, schrieb [hidden email]:

> 23.12.2010 17:52, Marco van de Voort пишет:
>> In our previous episode, [hidden email] said:
>>>> Therefore, until the time someone finds a cross-platform way to
>>>> implement packages, I see no reason not to start on RTTI. They can
>>>> perfectly be implented independently
>>>> or even in parallel.
>>>>
>>> Wine has ability to load windows libraries on linux.
>> .. into windows programs.
>>
>>> This technology could be used to implement cross-platform packages.
>> Yes, run the FPC/win32 binary in Wine :-)
>>
>> _______________________________________________
>> fpc-pascal maillist - [hidden email]
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>>
>
> I`ve heard that some cross-platform projects use this to build
> cross-platform plug-ins.

Yeah... and only works on i386- and x86_64-linux.

Runtime packages will come sooner or later, maybe not this year (ok...
that's hard to beat ^^) and maybe not next year. But when they come
they'll be implemented in a good cross platform way without such hackish
approaches like requiring Wine or some other big dependencies.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
24.12.2010 17:31, Sven Barth пишет:
>
> Yeah... and only works on i386- and x86_64-linux.
>
> Runtime packages will come sooner or later, maybe not this year (ok...
> that's hard to beat ^^) and maybe not next year. But when they come
> they'll be implemented in a good cross platform way without such
> hackish approaches like requiring Wine or some other big dependencies.
>
>

I mentioned WINE only as as example of possibility to use native
binaries from one platform in another. FPC should use own format of
dynamic library and own dynamic linker code embedded into executable.
This solution could be crossplaform.

Regards,
Alexander

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
123