Tareas repetitvas en tiempo de diseño

[anubis]

Si si, gracias, lo que digo es que no entiendo como se implementa de esa forma, con los controles dataware en lazarus, que no se por donde estan o como se usan.

[Ñ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