Tareas repetitvas en tiempo de diseño

[Ñuño Martínez]

Es que eso de recorrer la lista de componentes... Nunca ha terminado de gustarme lo del RTTI. Que sí, que será muy útil, pero no termino de verlo.

[roman]

Empezado por Ñuño Martínez

Nunca ha terminado de gustarme lo del RTTI.

¿Quién dijo RTTI?

LineComment Saludos

[Ñuño Martínez]

Lo de recorrer la lista de componentes de un formulario, ¿no necesita RTTI para que funcione? Pregunto.

[mamcx]

No. Lo que trae Delphi de fabrica es similar a crear mi propio arreglo (matriz) de componentes y exponer una propiedad para poder evaluarlo.

Basicamente, al poner un control se hace algo como: Formulario.ObjetoPadre.Add(ObjetoHijo). Y eso a donde va? a un arreglo.

RTTI tiene que ver con "Introspección", que es la habilidad de poder evaluar las características del entorno/runtime/código desde dentro del mismo runtime. Si es un poco "deficiente" en Delphi, es que eso es un problema universal en los lenguajes con compilador Y tipos estáticos y sin un soporte de runtime potente, que es casi todos. Y es muy facil y natural en lenguajes con tipos dinámicos (como python), interprete (que es un introspector!) o con compiladores dinámicos (JIT). Por eso en .NET/Java es ligeramente mas potente la introspección (aunque sigue siendo engorroso en contraste con el codigo normal). En donde introspección/código normal es casi que lo mismo es en lenguajes homoiconicos como LISP, FORTH y demás.

[roman]

Tal como dice Mario. Aunque por un momento me ha entrado la duda de si el operador is -que casi seguro sería necesario en este contexto- no cae en el terreno de RTTI.

LineComment Saludos

[[AgustinOrtu]]

Si no estoy equivocado, el operador is esta implementado mediante RTTI, lo cual lo hace "seguro" y "completo"; tambien devolveria True en los casos en que los objetos, pudiendo ser de distintas clases, son de asignacion compatible; esto tambien aplicaría a interfaces (siempre y cuando se declaren con GUID)

Por otro lado por eso sigo pensando que la opcion 2 es mas segura en este caso, pudiendo usar colecciones con tipos genericos, o si se trata de las versiones mas antiguas de Delphi, un array of TDBxxx

[roman]

Empezado por AgustinOrtu

Si no estoy equivocado, el operador is esta implementado mediante RTTI, lo cual lo hace "seguro" y "completo";

Es posible que esté implementado como dices. Pero, por otro lado, la funcionalidad de is es la que esperaría tener en cualquier lenguaje orientado a objetos, siendo la herencia una de las premisas fundamentales en OOP. Por ello no sé qué tanto pueda calificar como RTTI.

Empezado por AgustinOrtu

tambien devolveria True en los casos en que los objetos, pudiendo ser de distintas clases, son de asignacion compatible; esto tambien aplicaría a interfaces (siempre y cuando se declaren con GUID)

Esto no lo entiendo. En la versión en la que me quedé (la 7), A is C significa A es de la clase C o desciende de ella. Nada más. No sé que signifique "asignación compatible". Y en el caso de interfaces, al menos en la versión 7, el operador is no sirve. Es el operador as el que puede o no usarse según declares el GUID o no.

Empezado por AgustinOrtu

Por otro lado por eso sigo pensando que la opcion 2 es mas segura en este caso, pudiendo usar colecciones con tipos genericos, o si se trata de las versiones mas antiguas de Delphi, un array of TDBxxx

Je, je. Pues yo sigo pensando que lo más fácil es mi opción pues no hay más que asignar un evento y asignar alguna variable

LineComment Saludos

[Ñuño Martínez]

Veo que la duda que tenía es bastante común (si "IS" necesita RTTI o no). Si no recuerdo mal, Delphi 6 (que es donde me quedé yo) necesita que se compile con RTTI para que IS funcione. No sé si en versiones posteriores han optimizado algo y ya no es necesario.

[[AgustinOrtu]]

Por ejemplo esto:

Código Delphi [-]
program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

type
  IAdderSubstractor = interface
    function Sumar(const A, B: Integer): Integer;
    function Restar(const A, B: Integer): Integer;
  end;

  IHelloWorld = interface
    procedure SayHelloWorld;
  end;

  TCalculadora = class(TInterfacedObject, IAdderSubstractor, IHelloWorld)
  public
    function Sumar(const A, B: Integer): Integer;
    function Restar(const A, B: Integer): Integer;

    procedure SayHelloWorld;
  end;

  TOtraClase = class
  public
    procedure Say(const AText: string);
  end;

function TCalculadora.Restar(const A, B: Integer): Integer;
begin
  Result := A - B;
end;

procedure TCalculadora.SayHelloWorld;
begin
  Writeln('Hello world');
end;

procedure TOtraClase.Say(const AText: string);
begin
  Writeln(ClassName + ' ' + AText);
end;

function TCalculadora.Sumar(const A, B: Integer): Integer;
begin
  Result := A + B;
end;

var
  OtraClase: TOtraClase;
  Calculadora: TCalculadora;
  AdderSubstractor: IAdderSubstractor;

begin
  AdderSubstractor := TCalculadora.Create;
  if AdderSubstractor is TCalculadora then
    Calculadora := TCalculadora(AdderSubstractor);

  OtraClase := TOtraClase(AdderSubstractor);

  try
    try
      Writeln(IntToStr(AdderSubstractor.Sumar(10, 5)));
      Writeln(IntToStr(Calculadora.Restar(10, 5)));
      OtraClase.Say('Hola!');
    except
      on E: Exception do
        Writeln(E.ClassName, ': ', E.Message);
    end;
  finally
    Readln;
  end;
end.

Una clase puede implementar varias interfaces; luego, mediante el operador is me aseguro de que puedo realizar un cast sin problemas

El problema del codigo anterior es que la linea OtraClase := TOtraClase(AdderSubstractor);, no solo que compila perfecto, sino que no da error en runtime; hasta que se intenta usar la clase. Evidentemente se produce un access violation al invocar al metodo Say

Luego, otra variante es el uso del as

Código Delphi [-]
OtraClase := AdderSubstractor as TOtraClase;

Eso tambien compila perfectamente pero eleva una excepcion EInvalidCast