Czy kiedykolwiek, w praktyce, potrzebowaliście namespaców? Opcje

[konrados]

Cześć.

Jak w pytaniu, czy kiedykolwiek, w praktyce, potrzebowaliście namespaców? Nie chodzi o używanie, tylko rzeczywistą potrzebę.

Stworzyłem już parę średniej(?) wielkości serwisów (nie wiem jak to konkretnie zdefiniować, ale były to CRM, czy system mikrokredytów).

I nigdy nie potrzebowałem użycia namespaces. W użyciu był tylko jeden framework, było sobie ~20 kontrolerów i ~20 modeli, oraz może z trzy zewnętrzne biblioteki.

Nigdy nie było nawet ryzyka zaistnienia jakiejkolwiek kolizji nazw.

Teraz przysiadam się do poprawek pewnego projektu w YII2 i wszędzie muszę wpisywać use siaki namespaces/podnamespace/podpodnamespace a potem kolejne use to i siamto tylko dlatego, że chcę użyć jakiejś klasy.

To jakiś obłęd... Tu też w użyciu jest jeden framework, żadnych dodatkowych bibliotek a ja się muszę męczyć i tracić czas.

Ja wiem, że to jest "pro" i w ogóle, ale tak w praktyce na 10 ostatnich projektów, w ilu wam to było naprawdę przydatne?

[Pilsener]

...czy kiedykolwiek, w praktyce, potrzebowaliście namespaców?

- nie.

Nigdy nie było nawet ryzyka zaistnienia jakiejkolwiek kolizji nazw.

- standardy typu PSR przewidują, że nazwa klasy to nazwy folderów plus nazwa pliku a ponieważ w jednym folderze może być tylko jeden plik o jednej nazwie... Nie widzę tu związku z używaniem namespace.

Moje doświadczenia z pracy z projektami gdzie używa się namespace (niezależnie od tego, czy nazwy klas są zgodne np. z PSR-3 jak np. w fw z1 czy nie):
1. Zaśmiecenie początku pliku definicjami "use" - dodatkowy czas (na skrolowanie i zarządzanie tym, mam klasy gdzie jest po 100 "juzów", ktoś zapomni "juza" dodać, ktoś usunąć itp. itd. etc.).
2. Potrzeba tworzenia aliasów - mamy np. dwie klasy "user" ale z różnych namespace, co teraz?
3. Poświęcenie przejrzystości kodu dla zwięzłości (jestem przeciwnikiem tego paradygmatu) - potrzebuję więcej czasu by widząc w kodzie klasę "user3" ustalić jej pełną nazwę, w dodatku argument zwięzłości też się sypie gdy okazuje się, że 99% "jusów" dotyczy tylko jednej użytej w kodzie klasy, w 99% mamy po prostu nazwy klas w dwóch miejscach i tyle dodatkowych linijek, ile tworzymy obiektów - jaka tu zaleta dla programisty?
4. Wydłużenie nazw klas - kiedyś klasy nazywało się A_B_C, teraz A_B to namespace a C w kodzie nic nie mówi, więc nazwa klasy jest: A_AB_ABC (co znamy dobrze choćby z fw s2) po to, aby wilk (trend w programowaniu) był syty i owca (programista) cała (IMG:style_emoticons/default/facepalmxd.gif)

jakoś to do mnie nie przemawia

- do mnie też (IMG:style_emoticons/default/thumbsdownsmileyanim.gif)

[by_ikar]

- nie.

- standardy typu PSR przewidują, że nazwa klasy to nazwy folderów plus nazwa pliku a ponieważ w jednym folderze może być tylko jeden plik o jednej nazwie... Nie widzę tu związku z używaniem namespace.

Moje doświadczenia z pracy z projektami gdzie używa się namespace (niezależnie od tego, czy nazwy klas są zgodne np. z PSR-3 jak np. w fw z1 czy nie):
1. Zaśmiecenie początku pliku definicjami "use" - dodatkowy czas (na skrolowanie i zarządzanie tym, mam klasy gdzie jest po 100 "juzów", ktoś zapomni "juza" dodać, ktoś usunąć itp. itd. etc.).
2. Potrzeba tworzenia aliasów - mamy np. dwie klasy "user" ale z różnych namespace, co teraz?
3. Poświęcenie przejrzystości kodu dla zwięzłości (jestem przeciwnikiem tego paradygmatu) - potrzebuję więcej czasu by widząc w kodzie klasę "user3" ustalić jej pełną nazwę, w dodatku argument zwięzłości też się sypie gdy okazuje się, że 99% "jusów" dotyczy tylko jednej użytej w kodzie klasy, w 99% mamy po prostu nazwy klas w dwóch miejscach i tyle dodatkowych linijek, ile tworzymy obiektów - jaka tu zaleta dla programisty?
4. Wydłużenie nazw klas - kiedyś klasy nazywało się A_B_C, teraz A_B to namespace a C w kodzie nic nie mówi, więc nazwa klasy jest: A_AB_ABC (co znamy dobrze choćby z fw s2) po to, aby wilk (trend w programowaniu) był syty i owca (programista) cała (IMG:style_emoticons/default/facepalmxd.gif)

- do mnie też (IMG:style_emoticons/default/thumbsdownsmileyanim.gif)

AD1. Jeżeli masz w klasie 100x USE, to czas się zastanowić, czy twoja klasa nie jest bezsensu. Dodać use? Edytor dodaje to sam. Usunąć use? Edytor podkreśla nieużywane zmienne/klasy/przestrzenie/definicje etc. Warunkiem jest używanie IDE a nie notatnika.

AD2. Ale ten alias stworzyć możesz, bez przestrzeni nazw, tego aliasu stworzyć nie możesz i musisz zmieniać nazwę swojej klasy.

AD3. W normalnym edytorze po najechaniu kursorem na klasę masz albo ścieżkę jej pochodzenia, albo jej przestrzeń nazw. O ficzerach jak: go to declaration, find usages, go to implementations - nawet nie wspomnę, bo takich rzeczy w notatniku nie ma.

AD4. nazwa klasy się nie wydłuża. Nazwa klasy jest krótsza niż "zendowy" standard, dlatego że raz użyte "use" zwalnia cię z potrzeby pisania tego drugi raz. A_AB_ABC - chciałbym zobaczyć przykład.

Też miałem kiedyś problem z namespace, ale zrozumiałem że to nie jest problem namespace samego w sobie (w innych językach istnieją tylko namespace), a jest to problem edytora i najwyższy czas przestać klepać w notatniku. Zmieńcie swoje notatniki na jakieś konkretne edytory, to odczujecie różnice. Osobiście praktycznie nie piszę use wcale, całą robotę odwala za mnie edytor. Tak samo kasowanie nieużywanych use. W normalnych edytorach takie rzeczy (i wiele więcej) można sobie ustawiać. W notatniku to sobie możesz.. W sumie nic nie możesz.

Zauważyłem że większość przeciwników namespaców, to są albo początkujący, dla których każdy dodatkowy schodek, to jest przepaść. Albo ludzie którzy zatrzymali się w pechapie na poziomie początków php5..

Ten post edytował by_ikar 4.09.2014, 19:19:31