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" <mich...@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@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
