Saber si un método tiene implementación

[poyo]

Bueno, actualicé eso que veníamos hablando en el otro hilo de las VMT y actualicé el RTTIUtils.pas y lo subí al FTP (en Delphi-Win32/Recursos):

http://www.terawiki.clubdelphi.com/a.../RttiUtils.zip

Bueno, además de lo que estaba, le agregué una función que salió de esta conversación. Es la siguiente:

function IsOverrideMethod(AClass, Ancestor: TClass; MethodIndex: Integer ): boolean;

Adentro se chequea que los argumentos sean válidos y luego Itera por la jerarquía de herencias...
mmmm..... ahora que lo pienso a lo mejor está de más eso...
no sé... bué... ya está, luego veremos.

Ejemplo de Uso:

Código Delphi [-]
TPadre = class (TObject)
   procedure a; virtual; abstract;
   procedure b; virtual;
 end;

 THijoA = class (TPadre)
   procedure a; override;
 end;

 THijoB = class (TPadre)
   procedure b; override;
 end;

 THijoC = class (THijoB)
   procedure a; override;
   procedure b; override;
 end;

 THijoD = class (THijoC)
 end;

 THijoE = class (TPadre)
 end;

 THijoF = class (THijoD)
   procedure a; override;
 end;

 THijoG = class (THijoE)
 end;

 THijoH = class (THijoG)
 end;

implementation

uses 
  rttiutils;

procedure TPadre.b;
begin
end;

procedure THijoA.a;
begin
end;

procedure THijoB.b;
begin
end;

procedure THijoC.a;
begin
end;

procedure THijoC.b;
begin
end;

procedure THijoF.a;
begin
end;

procedure check(AClass: TClass);
begin
  if IsOverrideMethod(AClass,TPadre,0) then
    Showmessage(Aclass.ClassName + ': Index 0 = Override!');
  if IsOverrideMethod(AClass,TPadre,1) then
    Showmessage(Aclass.ClassName + ': Index 1 = Override!');
end;


procedure TForm1.FormCreate(Sender: TObject);
begin
  Check(THijoA);
  Check(THijoB);
  Check(THijoC);
  Check(THijoD);
  Check(THijoE);
  Check(THijoF);
  Check(THijoG);
  Check(THijoH);
end;

Se escuchan comentarios, sugerencias y derivadas

[gushynet]

Hola de nuevo. Voy a intentar explicar lo que estoy haciendo.

Me he creado una clase llamada TUniverso. Esta clase es la clase base a partir de la cual heredan todas las posibles clases que necesite para mis aplicaciones.

Por otro lado tenemos una jerarquia de contenedores cuya clase base es TContenedor y desciende directamente de TUniverso.

TUniverso tiene una serie de operaciones : asignar, duplicar, comparar,EsMayor,...

La cuestion es que todos los objetos que haga son descendientes de TUniverso, por lo que tambien se podran usar los métodos antes descritos.

La gracia del asunto es que he usado RTTI en TUniverso de forma que no se tenga que implementar en las clases que te hagas las funciones tipicas de comparar dos objetos, asignar un objeto a otro,.....

Todo esto funciona para las propiedades publicadas claro.

Por otro lado tenemos la jerarquia contenedor. Estos contenedores guardan cosas del tipo TUniverso o descendiente. Esta jerarquia de contenedores tiene contenedores para guardar elementos del mismo tipo, tipos distintos e incluso elementos repetidos. Hay listas,colas,pilas,arboles,tablas hash,....


Tambien he implementado funciones de E/S para escribir y leer objetos desde fichero.


En definitiva lo que queria hacer era una jerarquia de contenedores genericos. La unica condicion que se impone es que los objetos deben descender directa o indirectamente de TUniverso.

Ahora estoy con las operaciones de E/S.
La forma en que escribo el objeto en disco es igual para objetos simples o complejos. Entiendo un objeto complejo como uno que ademas de tener propiedades simples,enteras,caracteres,....tiene propiedades de tipo objeto, como los contenedores que explique antes.

Dentro de las operaciones de E/S hay dos métodos abstractos (llamemosre EscribirRegistro y LeerRegistro cuya implementacion se deja para el usuario que crea una clase a partir de TUniverso. Razón de estos métodos:

Entiendo que al ahora de guardar un objeto en memoria lo normal es crearse un tipo de registro que albergue las propiedades del objeto que nos interesa guardar. Los métodos del parrafo anterior hacen eso, escribe o lee el registro equivante del objeto en el fichero.

Como no todas las clases de TUniverso necesitan implementar las funcionalidades de E/S puede que haya clases derivadas de TUniverso que no implementen LeerRegistro y EscribirRegistro.

Existe una funcion llamada AddToFile que añade el objeto actual al fichero. Esta funcion es virtual. En TUniverso se implementa de una manera, la cual sirve para objetos simples. Pero en TContenedor cambia la implementacion al ser el objeto un contenedor.

Estoy en un punto en el que estoy insertando unos objetos en un fichero. Este fichero (no lo he dicho) tiene informacion de control para poder localizar los objetos. El problema que tengo es que dentro del procedimiento en un punto debo saber si el objeto que estoy tratando ha cambiado la implementacion de AddToFile o no, ya que la informacion de control que guarde depende de ello.

A parte de la solucion que consiga, la verdad es que me gustaria saber si es posible sacar este tipo de informacion de un objeto.




Pues ya esta, realmente no es como me hubiera gustado explicarlo, pero espero que ahora el contexto del problema este mas claro


PD: de nuevo disculpas por mi mania de responder a los mensajes por el final, ya que se puede dar el caso de que hayan dado una solucion y yo sigo engordando el hilo.

Saludos y gracias por la ayuda que me estan brindando.

[gushynet]

Una duda que no merece respuesta pero para las horas muertas o para cuando estas bloqueao y no te sale el codigo, da mucho de si:

en que leguaje esta hecho matrix? en VB, delphi, BASIC,.... y si esta hecho VB quiere decir que microsoft esta detras de matrix?

Esto es lo que pasa cuando se esta hasta altas horas de la noche intentadando domar a la bestia de transistores, las dudas empiezan a degradarse

[[Al González]]

Gracias por las aclaraciones.

Pues creo que puede servirte perfectamente una función como RedefineProc2. ¿Ya lo probaste?

Aunque no sé si sea la mejor manera de atacar el problema (tendría que ver una muestra de tu código para intentar idear otra forma de resolverlo). Pero de que te funcionará, funcionará.

Si pudieras plasmar lo que has dicho en una jerarquía simplificada de tres o cuatro clases con unos pocos métodos y sentencias esenciales, sería estupendo.

[gushynet]

Hola, pues gracias a las aportaciones de todos los que os habeis interesado por el tema ya se por donde van los tiros.

AL Gonzales (ahora si lo escribi bien ) no he probado el codigo, mas que nada porque prefiero primero entender bien como funciona el tema de la tabla virtual y realizar mi propio codigo ya que si no no se aprende . De todas formas si a alguien le interesa lo que estoy haciendo no tiene nada mas que pedirme el codigo. Probablemente tendra algunos errores (poco optimizado o nada) pero creo que es una buena manera de conocer un poco las RTTI, asi que si alguien lo quiere....


Otra duda: el uso de las RTTI merman el rendimiento de una aplicación? la duda viene de que las funciones RTTI entiendo que tienen que navegar por la jerarquia de clases y eso debe ser desde un punto de vista computacional muy costoso? estoy en lo cierto?

Y otra pregunta mas: con las RTTI he conseguido informacion sólo sobre propiades de la seccion published. Se puede ir mas lejos y poder conseguir en tiempo de ejecucion informacion sobre propiedades que esten en las otras secciones?

e informacion sobre variables?

por lo que he visto solo se permite para propiedades (y no variables) que esten declaradas en published, pero teniendo en cuenta la falta de documentacion sobre las RTTI a lo mejor si es posible obtener informacion de cualquier componente, sea simple o no, de un objeto.

Gracias por la información.
Un saludo.

PD: una curiosidad, ¿cuantas horas dedicais, en vuestro tiempo libre, a delphiar, ya sea porque os estais haciendo una aplicacion, por probar caracteristicas del lenguaje o entorno, porque para ustedes programar es como para un pintor hacer un cuadro,....

[[Al González]]

Empezado por gushynet

AL Gonzales (ahora si lo escribi bien )...

No, pero ya vas mejorando.

Empezado por gushynet

no he probado el codigo, mas que nada porque prefiero primero entender bien como funciona el tema de la tabla virtual y realizar mi propio codigo ya que si no no se aprende

Es bueno que al final uno escriba o al menos comprenda todo el código que da solución a un problema, pero empezar por hacer pruebas con lo ya existente no me parece nada desventajoso, al contrario, es una forma muy buena de aprender.

Vuelvo a poner la función que da solución al problema que planteas:

Código Delphi [-]
{ Función para saber si Obj redefine el método Proc2.  Código para métodos
  virtuales abstractos y no abstractos. }
Function RedefineProc2 (Const Obj :TA) :Boolean;
Type
  TMetodo = Procedure Of Object;
Var
  Metodo :TMethod;
  EntradaVMT :Pointer;
Begin
  EntradaVMT := TA;

  Asm
    { De la VMT de TA, obtenemos la entrada que guarda la dirección del
      método Proc2 (cuando el método es abstracto, esa entrada contiene la
      dirección de memoria del procedimiento _AbstractError) }
    Add EntradaVMT, VMTOffset TA.Proc2
  End;

  TMetodo (Metodo) := Obj.Proc2;
  Result := Metodo.Code <> Pointer (EntradaVMT^);
End;

Donde dice Proc2, sólo debes poner el nombre del método en cuestión, y donde dice TA, el nombre de la clase base en cuestión. Por favor, pregunta por los elementos que te resulten desconocidos o confusos.

Empezado por gushynet

De todas formas si a alguien le interesa lo que estoy haciendo no tiene nada mas que pedirme el codigo. Probablemente tendra algunos errores (poco optimizado o nada) pero creo que es una buena manera de conocer un poco las RTTI, asi que si alguien lo quiere...

Yo me apunto, en mi perfil está mi correo. Pero creo que sería mejor subirlo como archivo anexo, o al menos publicar las partes esenciales entre etiquetas "Delphi" dentro del mismo hilo, para que todo mundo pueda verlo sin mayor protocolo.

Empezado por gushynet

el uso de las RTTI merman el rendimiento de una aplicación? la duda viene de que las funciones RTTI entiendo que tienen que navegar por la jerarquia de clases y eso debe ser desde un punto de vista computacional muy costoso? estoy en lo cierto?...

No. O al menos depende de qué información se la que consultes. Para lectura y comparaciones de punteros, como las anteriores, el consumo adicional de recursos no es significativo. Pero en el caso de propiedades publicadas que haya que consultar por su nombre expresado en un String, sí puede ser mayor. Sin embargo, al final de cuentas de penderá de cada situación en particular.

Empezado por gushynet

con las RTTI he conseguido informacion sólo sobre propiades de la seccion published. Se puede ir mas lejos y poder conseguir en tiempo de ejecucion informacion sobre propiedades que esten en las otras secciones?

e informacion sobre variables?

por lo que he visto solo se permite para propiedades (y no variables) que esten declaradas en published, pero teniendo en cuenta la falta de documentacion sobre las RTTI a lo mejor si es posible obtener informacion de cualquier componente, sea simple o no, de un objeto.

En efecto, las propiedades deben ser publicadas (estar declaradas en la sección Published), pero además es necesario que la clase sea compilada bajo la directiva {$M+} (o su equivalente {$TypeInfo On}), o descienda de una clase que haya sido compilada con esa directiva. Es el caso, por ejemplo, de todos los derivados de TPersistent, cuya declaración dentro de la unidad Classes.pas (Delphi 7) es:

Código Delphi [-]
{$M+}

  TPersistent = class(TObject)
  private
    procedure AssignError(Source: TPersistent);
  protected
    procedure AssignTo(Dest: TPersistent); virtual;
    procedure DefineProperties(Filer: TFiler); virtual;
    function  GetOwner: TPersistent; dynamic;
  public
    destructor Destroy; override;
    procedure Assign(Source: TPersistent); virtual;
    function  GetNamePath: string; dynamic;
  end;

{$M-}

Así mismo opté por declarar una clase recientemente en este otro caso, para que el compilador me generara información RTTI de una propiedad (ya que no basta que la propiedad sea publicada): http://www.clubdelphi.com/foros/show...6&postcount=12

Esto es lo que dice la ayuda sobre esa directiva:

Type Switch

Syntax {$M+} or {$M-}
{$TYPEINFO ON} or {$TYPEINFO OFF}

Default {$M-}
{$TYPEINFO OFF}
Scope Local

The $M switch directive controls generation of runtime type information (RTTI). When a class is declared in the {$M+} state, or is derived from a class that was declared in the {$M+} state, the compiler generates runtime type information for fields, methods, and properties that are declared in a published section. If a class is declared in the {$M-} state, and is not derived from a class that was declared in the {$M+} state, published sections are not allowed in the class. Note that if a class is forward declared, the first declaration of the class must be declared with the $M switch.

When the $M switch is used to declare an interface, the compiler generates runtime type information for all properties and methods. That is, for interfaces, all members are treated as if they were published.

Note: The TPersistent class defined in the Classes unit of the component library is declared in the {$M+} state, so any class derived from TPersistent will have RTTI generated for its published sections. The component library uses the runtime type information generated for published sections to access the values of a component's properties when saving or loading form files. Furthermore, the IDE uses a component's runtime type information to determine the list of properties to show in the Object Inspector.

Note: The IInvokable interface defined in the System unit is declared in the {$M+} state, so any interface derived from IInvokable will have RTTI generated. The routines in the IntfInfo unit can be used to retrieved the RTTI.

There is seldom, if ever, any need for an application to directly use the $M compiler switch.

Cabe mencionar que Borland hace una sutil separación entre el término RTTI y otros que a veces asociamos con él, como VMT. Aunque en términos generales todo es Run Time Type Information (RTTI), la ayuda de Delphi emplea el término RTTI para referirse principalmente a la información que describe las partes publicadas de las clases. Mucha de esa información es obtenida con las funciones de la unidad TypInfo, y su origen se remonta a la primera versión de Delphi, para fines de almacenamiento y lectura de los componentes en los archivos DFM. Mecanismos de streaming que siguen vigentes.

Por otra parte, la Tabla de Métodos Virtuales (VMT) existe desde que Turbo Pascal vino a proponer destacadamente la programación orientada a objetos. Ya desde entonces Borland había diseñado una ingeniosa forma de guardar apuntadores a los métodos que podrían ser redefinidos (reimplementados) de una clase a otra dentro de la jerarquía. De tal forma que cada clase es en realidad su VMT, una tabla que la describe y que no sólo guarda punteros a métodos virtuales, sino una cantidad significativa de "meta código" adicional.

Estas VMTs y la información que contienen no dependen de si la clase está compilada con la directiva $TypeInfo o no, su información comprende elementos privados (Private), protegidos (Protected), públicos (Public) y publicados (Published). Pero algo de saber es que no guarda detalle de todos ellos, sino nada más de los que son "clave" para realizar ciertas tareas, como por ejemplo la finalización de campos ("variables" del objeto) que usan contadores de referencia, como es el caso de los campos de tipo String.

Empezado por gushynet

PD: una curiosidad, ¿cuantas horas dedicais, en vuestro tiempo libre, a delphiar, ya sea porque os estais haciendo una aplicacion, por probar caracteristicas del lenguaje o entorno, porque para ustedes programar es como para un pintor hacer un cuadro,....

En mi caso, el tiempo libre es cuando juego baloncesto, leo un libro por gusto, doy un paseo por el parque o veo un filme. Todo lo que hago con Delphi, incluyendo el ayudar a otros, lo considero una responsabilidad, que asumo con gusto, claro.

Un abrazo en tiempo de ejecución.

Al González.

[gushynet]

Buenas, antes de poner el codigo, una preguna mas: a lo largo de las versiones, delphi ha sufrido muchas modificaciones en las RTTI y el funcionamiento de la VTM, de forma que es complejo desde el punto de vista de la compatibilidad tener un codigo RTTI que sirva para distintas versiones de delphi?, la pregunta viene de que estoy haciendo algo generico pero que me sirva para cualquier version de delphi, pero si la situacion es (no lo se) que para cada version de delphi han salido modificaciones en las RTTI y VMT de forma que hace imposible la compatibilidad usando RTTI pues me llevaria un palo.


Saludos