É “implicitamente importado” sempre uma coisa ruim em pacotes de Delphi?

Question

Tentando reorganizar meus pacotes para um conjunto de TFrame-descendente componentes , eu estou achando aparentemente necessário quebrar alguns dos meus serviços públicos descendentes TFrame separar as formas de diálogo que os utilizam, principalmente porque o antigo se encontram registados na paleta como componentes verdadeiros e que parece confundir o IDE, por vezes, no que diz respeito às formas de diálogo que os utilizam. As formas de diálogo, por sua vez são chamados por componentes não visuais, os quais fazem parte de um terceiro pacote. Este, até agora , parece fazer a maior parte do compilador reclamações relacionadas com a dependência / confusões ir embora. (Eu não sou ainda, no entanto).

Ao compilar o pacote com as formas de diálogo (que chamar os quadros), estou recebendo o aviso de "Unidade 'MyFrames' importado implicitamente em pacote 'MyDialogForms'"

Uma vez que ele aparece como um aviso do compilador, já há muito tempo tido a impressão de que "implicitamente importar" uma unidade geralmente não é uma coisa boa. Existem casos específicos em que não é o caso? isto é, onde implicitamente importação de uma unidade é OK, e / ou uma prática apropriada? ... e se assim for, quais são esses casos específicos?

Answer 1

Aqui está o problema:

Você pode ter apenas uma cópia de uma unidade em seu programa. Se você tentar carregar a mesma unidade duas vezes através de pacotes, que irá gerar uma exceção e o pacote não irá carregar pela segunda vez. A maneira de evitar isso é para estruturar seus pacotes de modo que nenhum aparelho é utilizado em mais de um deles.

O código para cada unidade de compilar tem que ser no pacote. O compilador vai começar com todas as unidades que declaram no contém , mas quaisquer outras unidades utilizadas por essas unidades também tem de ser compilado em por isso vai ser acessível, a menos que essas unidades estão contidos em outro pacote que é listada em requer . Estes extras são as unidades "importados implicitamente". O problema é que eles são importados implicitamente , não explicitamente declarado na contém seção onde eles convenientemente aparecer no Project Manager para a direita. Isso significa que você pode não perceber que sua unidade está em um pacote, e acabam colocando-o em outro. Então, quando você tentar executar o seu programa e carregar os pacotes, as coisas quebram. É por isso que o compilador avisa sobre isso.

É um aviso, e não um erro, por uma razão. Contanto que você entender como funciona o sistema, é tecnicamente seguro para usar importações implícitas. Basta lembrar que essas unidades estão terminando no pacote se você declará-los ou não. Mas, novamente, uma vez que está terminando lá em cima se você declará-los ou não, é provavelmente mais simples apenas para oficialmente adicioná-los e salve-se o incômodo.

Answer 2

+1 para de Mason . O local onde as unidades implicitamente-importadas tornam-se um problema é em um projeto grande que se torna exponencialmente mais difícil manter o controle de unidades que estão ligadas a partir whereever.

I encontrar a melhor maneira de longe é ter uma pasta por pacote, e essa pasta contém todos os arquivos para o pacote. Se eu vejo um aviso "implícita de importação", eu adicionar o pacote requerido, ou adicionar a unidade ao pacote. Assim, todas as unidades são especificadas no pacote que contém-los e eles estão todos na mesma pasta. Eu nunca adicionar pastas ao caminho de pesquisa, porque cada projeto sabe sobre todos os seus arquivos diretamente.

A estrutura é realmente não muito difícil de manter e protege-lo de problemas em que diferentes unidades contêm diferentes versões de um arquivo.