[roman]

Empezado por AFilth

Supongo que es lógico ya que yo le estoy pasando un Objeto que aunque en realidad es de la ClaseB, Delphi lo interpreta como que es de la ClaseA.

Eso no tendría problema, pero:

El ejemplo que pones es incompleto y no vemos cómo estás construyendo el objeto que le pasas a GetInt64Prop. Fíjate en una cosa: TPersistent no es una clase virtual, esto es, su constructor Create no es virtual. Esto es importante, porque si construyes objetos a partir de referencias de clase- como lo es cuando usas el valor que devuelve GetClass -tal referencia debe apuntar a una clase virtual, de lo contrario, la construcción se resuelve desde el momento de la compilación usándose el constructor base de TPersistent y no el de la clase heredada.

Puedes resolver eso, metiendo un constructor virtual en tu clase A que incluso puedes dejar abstracto e implementarlo hasta la clase B, o bien dejarlo vacío (un procedimiento que no haga nada) y la clase B puede o no redefinirlo.

Pero cuando construyas la clase debes usar una referencia a tu clase A y no a TPersistentClass. Algo como:

Código Delphi [-]
type
  // Tu clase A
  TBaseObject = class(TPersistent)
    constructor Create; virtual; abstract;
  end;

  TBaseClass = class of TBaseObject;

Y usas TBaseClass para hacer un moldeo con el valor que te devuelve GetClass.

Código Delphi [-]
var
  AClass: TBaseClass;

begin
  AClass := TBaseClass(GetClass('TClaseQueDesciendeDeTBaseObject'));
  Base := AClass.Create;

  ...

end;

Como Aclass apunta ahora a una clase virtual, el compilador sabe ya que no puede resolver el constructor y debe dejarlo hasta el momento de la ejecución.

Otra cosa, es que no veo cómo estás definiendo la clase en cuestión: recuerda que las propiedades a las que quieres acceder deben estar en una sección published.

Además, en mi opinión, no hay necesidad de usar TPersistent. TPersistent y TComponent son las clases bases para el manejo de la persistencia en los archivos dfm. Si tú no requieres tal funcionalidad, no veo porqué usarlo.

Cualquier clase puede generar RTTI siempre y cuando se compile con la directiva {$M+}. Como TPersistent está compilado de esa forma, ella, y todas las classes descendientes, generan RTTI. Pero puedes lograr lo mismo si lo haces tú mismo:

Código Delphi [-]
type
  {$M+}
  type
    TBaseObject = class
      constructor Create; virtual; abstract;
    end;
  {$M-}

Claro que en esta situación no te va a servir GetClass. Pero GetClass y RegisterClass lo único que hacen es mantener una asociación:

nombre de clase => clase

que tú mismo puedes implementar fácilmente.


Y finalmente, de hecho no entiendo para qué quieres usar RTTI. Hasta donde recuerdo, tu puedes tener una unidad común, digamos Core que defina tu clase base, si quieres con sólo métodos abstractos para que haga lo mínimo indispensable. Entonces, incluyes esa unidad Core, tanto en la aplicación principal como en el paquete dinámico.

Dado que en Core estás definiendo la interfaz de tu clase, puedes acceder a los métodos y propiedades sin recurrir a las argucias de RTTI. Claro está, siempre y cuando te bases en una clase virtual, según te comenté arriba.

Eso sí, tienes que implementar tu propio registro

nombre de clase => clase

pero eso es relativamente sencillo. Puedes tener en Core un arreglo

Código Delphi [-]
var
  RegisteredClasses: array of TBaseClass;

y funciones globales:

Código Delphi [-]
RegisterBaseClass(Nombre: String; AClass: TBaseClass);
function GetBaseClass(Nombre: String): TBaseClass;

// Saludos