[fpc-pascal] The new Delphi 2010 RTTI

[Dimitri Smits]

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" <michael at freepascal.org> 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  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal