dbX depende de BDE ?

[rolandoj]

Hola a todos,

Agradezco toda la colaboración prestada.

Aparentemente ya resolví mi problema básico (vease el hilo http://www.clubdelphi.com/foros/showthread.php?t=53057) y en unos días daré detalles específicos porque creo que es una información particularmente útil para entender el funcionamiento primario de Delphi.

Les adelanto algo : Salvo que alguién aporte evidencia en contra, todo indica que hay dependencias entre los paquetes que no deberían ocurrir, confirmando en gran medida lo dicho por Al; pero, al menos en algunos casos, es problema de diseño y no de simple descuido de independizar paquetes al momento de compilar. Me explico, algunos paquetes no tienen separado su
acceso a Base de Datos de su código propio, de tal forma que se vuelven dependientes de un paquete que no deberían requerir.

[[Al González]]

¡Hola a todos!

Empezado por rolandoj

Hola Al,

Muchas gracias por los comentarios...Lo que planteas es que Borland no ha tenido cuidado de las relaciones entre paquetes, sino que ha confiado el asunto a un manejo automático...

No, lo que planteo es que dos paquetes están obligados relacionarse entre sí cuando hacen uso de una misma unidad y van a ser empleados por un mismo proceso (en este caso el entorno de Delphi). Al compilar paquetes, el encadenamiento se lleva a cabo conforme los paquetes que ya están cargados en memoria, pero el compilador siempre te avisa antes de generar un .bpl que requiere enlazarse a otro debido a que implícitamente utilizan (a través de las usualmente vastas cadenas de Uses) alguna unidad en común. No podría asegurar que sea un error o descuido de Borland que dbExpress y otros paquetes de componentes vengan de fábrica con una dependencia implícita hacia el paquete de tiempo de ejecución BDERTL, ya que si bien eso ahora parece no tener gran utilidad, en el pasado se veía como algo normal. Quizá es algo que CodeGear debe revisar y actualizarlo a esta época.

Empezado por rolandoj

...Si eso es así, implica cargas innecesarias de código al compilar los aplicativos ?...

La respuesta es un tajante no. Hay que dejar claro que cuando Delphi compila una aplicación no toma absolutamente nada de los paquetes para añadir al módulo ejecutable. Todo lo que necesita de código lo toma de las unidades compiladas individuales, es decir, de los archivos .dcu. Y sólo toma estrictamente lo que el propio código refiere de forma directa o indirecta. Puedes tener una biblioteca de miles de funciones independientes en una unidad .pas que luego, claro, es compilada como .dcu. Si tu programa utiliza una sola de esas funciones, sólo agregará al ejecutable lo que esa función hace y las dependencias dictadas por su código fuente, pero no las miles de líneas restantes. Al igual que tú he mirado la forma en que trabajan los productos de Borland desde Turbo Pascal y me consta que desde entonces han sido soberbios cuando de generar código máquina se trata. Borland ya generaba ejecutables optimizados cuando Microsoft apenas compraba su primer compilador real a unos canadienses porque eran incompetentes para crear uno propio.

Empezado por rolandoj

...Por otra parte, mencionas el caso de la unidad db. Esta unidad es la base común de las tecnologías de acceso a bases de datos , no parte del BDE. En ese orden de ideas debería estar en un paquete diferente, no en BDERtl100. Como sabes que forma parte de BDERtl100, o la mencionastes solo como un ejemplo general ?..

Hay que distinguir entre pertenencia o “formar parte de” y contención. Cuando creamos un paquete añadimos a él, de manera explícita, una o más unidades propias de la biblioteca de componentes que el paquete representa; decimos entonces que tales unidades forman parte del paquete, y ellas aparecen en la sección “Contains”. Pero esas unidades, a través de sus cláusulas Uses, suelen hacer referencias a otras unidades, incluyendo las nativas de la VCL. Si alguna de estas unidades ya está en otro paquete (cuyo BPL está cargado en memoria en ese momento), nuestro paquete se estaría haciendo dependiente de ese otro (no sin el oportuno aviso/pregunta del compilador), agregando una entrada a la sección “Requires”. Pero si tal unidad todavía no está siendo usada por ningún paquete que esté cargado en memoria, entonces nuestro paquete será el primero que la “haga suya”, de manera implícita. Sí, los paquetes “atrapan” a todas las unidades referidas a través de sus Uses, que no hayan sido “atrapadas” ya por otro paquete. Esto último es lo que provoca que subsiguientes compilaciones de paquetes que usen directa o indirectamente la misma unidad se vuelvan dependientes del primero que “tomó” a la unidad en discordia.

Te recomiendo el tema “Understanding the structure of a package” de la ayuda de Delphi, donde, entre otras cosas, se menciona:

Empezado por Borland

All units included directly in a package's contains clause, or included indirectly in any of those units, are bound into the package at compile time.

A unit cannot be contained (directly or indirectly) in more than one package used by the same application, including the IDE. This means that if you create a package that contains one of the units in vcl (VCL) or visualclx (CLX) you won't be able to install your package in the IDE. To use an already-packaged unit file in another package, put the first package in the second package's requires clause.

Empezado por rolandoj

...No he encontrado ningún BDERtl100.dpk, hay algún otro mecanismo para saber exactamente que unidades integran un paquete ?...

Sé que esa información se guarda en los archivos binarios .dcp, pero no recuerdo si Delphi cuenta con algún accesorio que permita consultarlos. En todo caso quizá exista alguna utilidad en la Red.

Empezado por rolandoj

...En general, a menos que uses aplicaciones pequeñas, no tengas unidades compartidas, uses un solo producto o no tengas que preocuparte por la flexibilidad, renombrar es una muy mala opción...

En esto creo que cada caso es único. Si bien es un buen argumento, no debemos perder de vista que la tecnología avanza perpetuamente, y es una labor normal y sana comenzar a separar o migrar (según convenga) los desarrollos más viejos conforme la línea tecnológica se “estira”. Según transcurren los años se vuelve más problemático tratar de mantener “en forma” todo un arsenal de código, que actualizar sólo las aplicaciones y bibliotecas de uso más vigente y redituable. Esto es una cuestión de enfoque donde se requiere evaluar muchos factores, caso por caso, pero sin perder objetividad. Si después de evaluar el tuyo a conciencia, aún crees que usar nombres de clases conflictivos es lo mejor, quizá el uso de clases interpuestas te resulte buena alternativa (aunque lo dudo porque intuyo mayores complejidades).

Empezado por rolandoj

...Debido a mi experiencia (más de 25 años dedicado exclusivamente a programar), yo soy fanático de la portabilidad y la capacidad de crecimiento. Digamos que es una lección que aprendí hace mucho tiempo...

Bueno, ojalá ese fanatismo se cure pronto para que no frene tu crecimiento como desarrollador. Comparto contigo el punto de buscar portabilidad y pensar “más allá de”, suelo hacerlo también. Pero en ocasiones hay que darle permiso al pragmatismo de inmiscuirse en nuestras vidas.

Empezado por rolandoj

...el código viene de una época en la que confiaba en Borland para la capa intermedia, que es quién debería haberse encargado. Como en eso hicieron un pobre trabajo, hoy en día ya no confío en ellos y estoy desarrollando mi propia capa intermedia.

Cordialmente te invito a que abras otro hilo con ese interesante tema. Mira que estoy muy interesado en todo lo que tiene que ver con programación multicapa. Ahí podrás plantearnos con debido espacio y tiempo el por qué confiabas y ahora no en ese aspecto de Borland/CodeGear.

Un abrazo empaquetado.

Al González.

[rolandoj]

Hola Al,

Muchas gracias por los largos comentarios. Creo que el tema lo amerita.

Como te dije, comentaré ampliamente el asunto; pero, por ahora estoy muy ocupado con las pruebas de la aplicación. Espero que el próximo fin de semana podamos intercambiar información y experiencias de esto con calma.

Solo una pregunta, como para abrir nuevo tema, por si tienes tiempo antes:

Con respecto a las versiones anterioes a la 2007, que he manejado, comparto al 100% tú opinión que el código del compilador Delphi es excelente; pero el del 2007, aún optimizando al máximo los parámetros de compilación, es mucho mayor que el del mismo programa en la versión previa. Leí que lo arreglaban en el Update 3; pero no ha sido así. Que sabes al respecto ?

Muchos saludos

[[Al González]]

Empezado por rolandoj

...Con respecto a las versiones anterioes a la 2007, que he manejado, comparto al 100% tú opinión que el código del compilador Delphi es excelente; pero el del 2007, aún optimizando al máximo los parámetros de compilación, es mucho mayor que el del mismo programa en la versión previa. Leí que lo arreglaban en el Update 3; pero no ha sido así. Que sabes al respecto ?...

De momento no estoy en condiciones de afirmar o negar que los ejecutables sean "mucho mayores" de tamaño. Y en caso de que realmente ocurra eso de manera consistente (y no por algún elemento ajeno al compilador, como podría ser una enorme imagen BMP en algún formulario), desconozco si existe un parche para ese hipotético problema.

Creo que por lo pronto Andreano podría respondernos a esta duda.

Edito:
Ahora que lo pienso, creo que sí podrían ser algo más grandes (habría que hacer pruebas para determinar la diferencia proporcional, y ver si esta es realmente mucha o poca) debido a la útil característica de las funciones "in-line" introducida en Delphi 2005. De momento es la única explicación teórica que tendría. Estaremos pendientes de ese detalle.

Saludos.

Al González.

[rolandoj]

Hola Al,

Como este caso te llamó la atención, y estas por probar Delphi 2007, te invito a que mires otro muy raro con que me he encontrado en las pruebas. Esta vez no se trata de hacer algo "no standard" sino de lo que creo es un error; pero ojala que no, porque para mi trabajo sería catastrófico.

Vale anotar que, aunque ni siquiera tendría que tener relación con el reemplazo de BDE, para este nuevo problema restauré los paquetes a su estado original.

El hilo es :

http://www.clubdelphi.com/foros/showthread.php?t=53141