¿Es "importado implícitamente" siempre algo malo en los paquetes de Delphi?

ide packages

Question

Al intentar reorganizar mis paquetes para un conjunto de componentes descendientes de TFrame , me parece que es necesario separar algunos de los descendientes de TFrame de mi utilidad separados de las formas de diálogo que los usan, principalmente porque los primeros están registrados en la paleta como verdaderos componentes y eso parece confundir el IDE a veces con respecto a los formularios de diálogo que los utilizan. Los formularios de diálogo a su vez son llamados por componentes no visuales, que forman parte de un tercer paquete. Esto, hasta ahora , parece hacer desaparecer la mayoría de las quejas / confusiones relacionadas con la dependencia del compilador. (No estoy fuera todavía, sin embargo).

Al compilar el paquete con los formularios de diálogo (que llaman a los marcos), recibo la advertencia "Unidad ''MyFrames'' importada implícitamente en el paquete ''MyDialogForms''"

Dado que aparece como una advertencia del compilador, hace mucho tiempo tuve la impresión de que "importar implícitamente" una unidad generalmente no es algo bueno. ¿Hay casos específicos donde ese no es el caso? es decir, donde la importación implícita de una unidad está bien y / o es una práctica adecuada ... y, en caso afirmativo, ¿cuáles son esos casos específicos?

Answer 1

+1 por la respuesta de Mason . El lugar donde las unidades importadas implícitamente se convierten en un problema es en un proyecto grande donde se vuelve exponencialmente más difícil hacer un seguimiento de las unidades que están vinculadas desde donde sea.

Creo que la mejor manera de hacerlo es tener una carpeta por paquete, y esa carpeta contiene todos los archivos para el paquete. Si veo una advertencia de "importación implícita", agrego el paquete requerido o agrego la unidad al paquete. Así que todas las unidades están especificadas en el paquete que las contiene y todas están en la misma carpeta. Nunca agrego carpetas a la ruta de búsqueda, porque cada proyecto conoce todos sus archivos directamente.

La estructura realmente no es muy difícil de mantener y lo protege de problemas donde diferentes unidades contienen diferentes versiones de un archivo.

Answer 2

Aquí está el problema:

Solo puede tener una copia de una unidad en su programa. Si intenta cargar la misma unidad dos veces a través de paquetes, generará una excepción y el paquete no se cargará la segunda vez. La forma de evitar esto es estructurar sus paquetes para que ninguna unidad se use en más de uno de ellos.

El código de cada unidad que compile debe estar en el paquete. El compilador comenzará con todas las unidades que declare en la sección de contenidos, pero cualquier otra unidad utilizada por esas unidades también debe compilarse para que sea accesible, a menos que esas unidades estén contenidas en otro paquete que se enumera bajo. Estos extras son las unidades "importadas implícitamente". El problema es que se importan de forma implícita , no se indica explícitamente en la sección de contenidos , donde se mostrarán de manera conveniente en el Project Manager a la derecha. Esto significa que es posible que no note que su unidad está en un paquete y termine de ponerla en otro. Luego, cuando intentas ejecutar tu programa y cargar los paquetes, las cosas se rompen. Es por eso que el compilador te lo advierte.

Es una advertencia, y no un error, por una razón. Mientras entienda cómo funciona el sistema, es técnicamente seguro utilizar importaciones implícitas. Solo recuerde que esas unidades están terminando en el paquete, ya sea que las declare o no. Pero nuevamente, ya que están terminando allí, ya sea que los declares o no, es probablemente más simple simplemente agregarlos oficialmente y ahorrarte la molestia.