Cómo conseguir paquetes dinámicos y no necesitarlos en DesignTime

[LoPiTaL]

Hola a todos!
Me asalta una nueva duda con la carga de paquetes en tiempo de ejecución. He seguido aténtamente este hilo http://www.clubdelphi.com/foros/showthread.php?t=68947
en el que Neftali explicaba de manera sublime los tipos de paquetes que podemos tener en nuestra aplicación.
Estoy desarrollando una aplicación en la que en un futuro esperamos hacerla crecer, por lo que me pareció interesante la carga dinámica de paquetes, así que me puse manos a la obra.
Tras darle varias vueltas, decidí por la opción (como dice el propio Neftali) más potente: BPLs cargados en runtime con la opción "Compile with Runtime Packages". Sencillamente funciona perfectamente.
El problema es que ahora me he dado cuenta que estos objetos (objetos maestros) que iré añadiendo a la aplicación, dependen también de otros objetos (objetos esclavos) que también me gustaría ir añadiéndolos dinámicamente.
Tengo la clase padre de ambos en un paquete en DesignTime, y los objetos maestros los puedo añadir fácilmente, derivando de su clase padre y registrándolos.
Pero éstos utilizan información sobre los objetos esclavos, la cual depende de qué tipo sea el esclavo, por lo que no puede estar en la clase padre de los objetos esclavos.
Por tanto, necesito tener información de ellos en DesignTime, por tanto se linkan estáticamente, por tanto, pierde la gracia hacer todo esto.

¿Me podríais indicar cómo puedo obtener información de estos objetos sin necesidad de tenerlos en DesignTime?
Yo estaba pensando en mantener records en DesignTime, y que al crear los objetos esclavos se le pase al constructor un puntero a dichos records.
El problema es que cualquier modificación en dicha estructura me obligaría a recompilar toda la aplicación...

Un saludo,
LoPiTaL

[ContraVeneno]

Me suena a que necesitas un BPL estático que te sirva de "puente" para tus cargas dinámicas.

Algo de esto se comenta en este enlace, podría servirte.

[LoPiTaL]

Gracias por la respuesta.

Lo que se comenta en ese hilo es lo que ya tengo:



Y eso funciona bien.
Ahora mi problema es que necesito que el Maestro hijo X acceda a información de los esclavos hijos Y, y dicha información, como es dependiente del tipo de esclavo que sea, no está en la clase padre.
Vamos quiero hacer esto otro:



Esa comunicación (marcada en rojo) es la que no sé cómo implementar sin caer en linkado estático, salvo añadiendo un BPL por cada esclavo hijo que únicamente contenga un pas con una estructura que sea la que el esclavo espera recibir, y a la que tendría acceso todo el mundo, por lo que este BPL sería estático, y un cambio en dicha estructura me obligaría a recompilar la aplicación.

¿Se os ocurre algo más? ¿Se me escapa algo?

Un saludo,
LoPiTaL

[ContraVeneno]

Desconozco la forma en que podrías tener "comunicación directa" entre dos BPL dinámicos. Lo que yo hago es hacer la comunicación a traves de un BPL Base. Tu podrías utilizar tu módulo maestro o esclavo para tener esa comunicación, pero sería indirecta.

Por eso yo hacía la mención de un BPL "Puente" que te sirva de camino.

[Neftali [Germán.Estévez]]

Siguiendo con lo que comenta Contraveneno, entiendo que hay dos formas de acceder a información de otros packages.

El primer problema es saber a qué te refieres con "comunicación"; No es lo mismo acceder a datos, crear objetos definidos en otro paquete, acceder a métodos de clase,...

(1) La forma directa pueder ser utilizando RTTI. Si tu aplicación está compilada con Runtime Packages, como debe ser, puedes utilizar técnicas de RTTI para acceder a determinados datos.

(2) La forma "indirecta" y es la que también uso yo, es la que ha comentado contraveneno. Utilizar una estructura en el package Base o en el programa principal para almacenar cosas que serán accesible por todos los packages.

Por ejemplo, en mi caso, tengo una "lista de Definiciones" en el package Base. Cada package que cargo añade a esa lista (accesible por todos los packages) su objeto definición (que contiene todo lo que los demás necesitan saber de ese package; constructores de clase, definiciones,...)

Una vez cargados los packages, en esa lista están los "objetos definición" de los packages cargados y los que no se han cargado no han añadido su "objeto definición".

[roman]

El problema, hasta donde veo, es que sus clases "maestras" hacen uso de clases "esclavas" específicas por lo que el paquete base tendría que incluir a todas ellas, aún las que no existan en el presente.

Obviamente es poco lo que se puede decir sin mayores datos, pero podría tratarse de un diseño de clases no del todo correcto. Las clases "esclavas" probablemente deberían de poderse acceder de manera genérica y dejar al polimorfismo la distinción de comportamientos.

// Saludos