Czy "niejawnie zaimportowane" zawsze jest złe w pakietach Delphi?

Question

Próbuję zmienić rozmieszczenie moich paczek na zestaw TFrame-descendent components, wydaje mi się, że pozornie konieczne jest rozbicie niektórych moich pomocniczych elementów TFrame osobno od formularzy dialogowych, które ich używają, głównie dlatego, że te pierwsze są zarejestrowane na palecie jako prawdziwe komponenty i to wydaje się mylić IDE czasami w odniesieniu do formularzy dialogowych, które je wykorzystują. Formularze dialogowe z kolei są wywoływane przez niewizualne komponenty, które są częścią trzeciego pakietu. To, do tej pory, wydaje się, że większość z kompilacji dependency-related complaints/confusions odejść. (Jeszcze nie jestem na zewnątrz).

Kompilując paczce z form dialogowych (co nazywamy ramkami), otrzymuję ostrzeżenie „niejawnie importowane do pakietu«MyDialogForms»jednostka«MyFrames»”

Biorąc pod uwagę to, że pokazuje się jako ostrzeżenie kompilatora, już dawno temu odniosłem wrażenie, że "niejawne importowanie" jednostki ogólnie nie jest dobrą rzeczą. Czy istnieją konkretne przypadki, w których tak nie jest? tj. gdzie domyślnie importowanie jednostki jest OK i/lub odpowiednia praktyka? ... a jeśli tak, to jakie są te konkretne przypadki?

Answer 1

Oto problem:

Można mieć tylko jedną kopię jednostki w programie. Jeśli spróbujesz załadować tę samą jednostkę dwukrotnie za pomocą pakietów, spowoduje to zgłoszenie wyjątku, a pakiet nie zostanie załadowany po raz drugi. Sposobem na uniknięcie tego jest uporządkowanie pakietów tak, aby żadna jednostka nie była używana w więcej niż jednym z nich.

Kod do każdej skompilowanej jednostki musi znajdować się w pakiecie. Kompilator rozpocznie się od wszystkich jednostek zadeklarowanych w sekcji zawiera, ale wszelkie inne jednostki używane przez te jednostki również muszą zostać skompilowane, aby były osiągalne, chyba że te jednostki są zawarte w innym pakiecie, który jest wymieniony pod wymaga. Te dodatki są jednostkami "domyślnie zaimportowanymi". Problem polega na tym, że są one zaimportowane niejawnie, bez wyraźnego oświadczenia w sekcji zawierającej, gdzie będą wygodnie pojawiać się w Menedżerze projektu z prawej strony. Oznacza to, że możesz nie zauważyć, że twoje urządzenie jest w paczce, a ostatecznie umieścić je w innym. Wtedy, gdy spróbujesz uruchomić swój program i załadujesz pakiety, wszystko się zepsuje. Właśnie dlatego kompilator ostrzega o tym.

To ostrzeżenie, a nie błąd, z jakiegoś powodu. Tak długo, jak rozumiesz, jak działa system, technicznie bezpieczne jest korzystanie z niejawnych importów. Pamiętaj tylko, że te jednostki kończą się pakietem, niezależnie od tego, czy je zadeklarujesz, czy nie. Ale z drugiej strony, ponieważ kończą się na tym, niezależnie od tego, czy je zadeklarujesz, czy nie, najprawdopodobniej po prostu oficjalnie je dodasz i uratujesz sobie kłopot.

Answer 2

+1 dla Mason's answer. Miejsce, w którym implicite zaimportowane jednostki stają się problemem, dotyczy dużego projektu, w którym wykładanie jednostek, z którymi się wiąże, staje się coraz trudniejsze wykładniczo.

Uważam, że najlepszym sposobem jest posiadanie folderu w pakiecie, a ten folder zawiera wszystkie pliki pakietu. Jeśli widzę ostrzeżenie "niejawny import", dodaję wymagany pakiet lub dodaję jednostkę do pakietu. Wszystkie jednostki są określone w pakiecie, który je zawiera i wszystkie znajdują się w tym samym folderze. Nigdy nie dodaję folderów do Ścieżki wyszukiwania, ponieważ każdy projekt wie bezpośrednio o wszystkich swoich plikach.

Struktura nie jest naprawdę trudna do utrzymania i chroni przed problemami, w których różne jednostki zawierają różne wersje pliku.