Est-ce que & # 8220; est implicitement importé & # 8221; toujours une mauvaise chose dans les paquets Delphi?

Question

Essayer de réorganiser mes packages pour un ensemble de composants descendant de TFrame , je le trouve apparemment nécessaire pour séparer certains de mes utilitaires descendants de TFrame des formulaires de dialogue qui les utilisent, principalement parce que les premiers sont enregistrés dans la palette comme de vrais composants et que cela semble confondre parfois l’IDE ??avec les formulaires de dialogue qui les utilisent. Les formes de dialogue sont à leur tour appelées par des composants non visuels, qui font partie d'un troisième package. Cela, jusqu'à présent , semble tirer le meilleur parti du plaintes liées à la dépendance / confusions disparaissent. (Je ne suis pas encore sorti, cependant).

Lors de la compilation du package avec les formulaires de dialogue (appelez les cadres), l'avertissement "Unité" MyFrames "est importé implicitement dans le package" MyDialogForms "&";

Etant donné que cela apparaît comme un avertissement pour le compilateur, j'ai depuis longtemps l'impression que "importer implicitement" et une unité n'est généralement pas une bonne chose. Y a-t-il des cas spécifiques où ce n'est pas le cas? C'est-à-dire qu'une importation implicite d'une unité est correcte et / ou une pratique appropriée? ... et si oui, quels sont ces cas spécifiques?

Answer 1

Voici le problème:

Vous ne pouvez avoir qu'un seul exemplaire d'une unité dans votre programme. Si vous essayez de charger deux fois la même unité via des packages, une exception sera levée et le package ne se chargera pas une seconde fois. Pour éviter cela, vous devez structurer vos packages de sorte qu'aucune unité ne soit utilisée dans plus d'un d'entre eux.

Le code de chaque unité que vous compilez doit figurer dans le package. Le compilateur commence par toutes les unités que vous déclarez dans la section contient , mais toute autre unité utilisée par ces unités doit également être compilée pour être accessible, à moins que ces unités ne soient contenues dans un autre package. qui est répertorié sous requiert . Ces extras sont les "implicitement importés" et unités. Le problème, c'est qu'ils sont implicitement importés, et non explicitement indiqués dans la section contient , où ils apparaîtront facilement dans le Gestionnaire de projets à droite. Cela signifie que vous ne remarquerez peut-être pas que votre appareil est dans un paquet et que vous finirez par le mettre dans un autre. Ensuite, lorsque vous essayez d'exécuter votre programme et de charger les packages, les choses se cassent. C'est pourquoi le compilateur vous en avertit.

C’est un avertissement, et non une erreur, pour une raison. Tant que vous comprenez le fonctionnement du système, il est techniquement sûr d’utiliser des importations implicites. Rappelez-vous simplement que ces unités se retrouvent dans le paquet, que vous les déclariez ou non. Mais là encore, comme ils se retrouvent là-bas, que vous les déclariez ou non, il est probablement plus simple de les ajouter officiellement et d’éviter les tracas.

Answer 2

+1 pour Réponse de Mason . L’endroit où les unités implicitement importées deviennent un problème concerne un grand projet où il devient de plus en plus difficile de garder une trace des unités liées à partir de n'importe où.

Je trouve que le meilleur moyen, de loin, est d’avoir un dossier par paquet, et ce dossier contient tous les fichiers du paquet. Si je vois une " importation implicite " avertissement, j’ajoute le package requis ou ajoute l’unité au package. Donc, toutes les unités sont spécifiées dans le paquet qui les contient et elles sont toutes dans le même dossier. Je n’ajoute jamais de dossiers au chemin de recherche, car chaque projet connaît directement tous ses fichiers.

La structure n'est pas vraiment difficile à maintenir et vous protège des problèmes lorsque différentes unités contiennent différentes versions d'un fichier.