¡Hola a todos!
Cita:
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.
Cita:
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.
Cita:
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:
Cita:
|
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.
|
Cita:
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.
Cita:
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).
Cita:
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.
Cita:
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.