Ocena przestrzeni nazw PHP


11

Jestem na etapie przedpremierowym projektu PHP typu open source, który, mam nadzieję, zostanie wykorzystany przez innych programistów we własnych projektach. Projekt obecnie nie obsługuje przestrzeni nazw i staram się ocenić, czy powinien używać przestrzeni nazw lub konwencji nazewnictwa PEAR z Dir_Subdir_Class, która wydaje się mieć wszystkie te same zalety techniczne bez pewnych wad. Szczerze mówiąc, nie jest to łatwy wybór.

Niektóre uwagi dotyczące przestrzeni nazw:

  • Jednym ze sposobów, w jaki mój projekt próbuje się wyróżnić, zapewniając prostszy interfejs API niż inne podobne projekty. Ponieważ przestrzenie nazw są nowe, a także dlatego, że są bardziej skomplikowane niż konwencja nazewnictwa PEAR, wprowadzenie ich do bazy kodu sprawi, że mój projekt będzie mniej prosty w użyciu. Wdrażając je, tracę pewne zróżnicowanie pod względem łatwości użytkowania.
  • Chociaż widzę pewne korzyści dla przestrzeni nazw, wydaje się, że nie rozwiązują one problemu, który należy rozwiązać w nowoczesnym produkcie PHP korzystającym z konwencji nazewnictwa PEAR. Konflikty nazewnictwa podczas korzystania z mojego projektu powinny być minimalne, jeśli nie istnieją.
  • W tym artykule zastanawiam się nad przyjęciem przestrzeni nazw, ponieważ ich implementacja była mniej niż gwiezdna.
  • Waham się również, by wskoczyć na modę, która nigdzie się nie pojawi. Ponieważ przestrzenie nazw są nową funkcją PHP, nie jestem jeszcze przekonany, że staną się standardem.
  • Zgodność. Prawie cały kod PHP, który kiedykolwiek został napisany, nie używa przestrzeni nazw, ponieważ jest to nowa funkcja. Inne biblioteki byłyby niezgodne bez konwersji.

Kilka punktów za korzystanie z przestrzeni nazw:

  • Postrzeganie. Jeśli przestrzenie nazw staną się standardem i najlepszą praktyką, mój projekt może szybko zostać uznany za nieprofesjonalny i przestarzały bez nich.
  • Konkurencja. Podczas gdy niektóre konkurencyjne projekty PHP zaczynają wykorzystywać przestrzenie nazw w swoich najnowszych wersjach, wiele jeszcze nie zrobiło skoku. Takie postępowanie może teraz zapewnić mojemu projektowi wsparcie w innych projektach.
  • Przyszłe prace byłyby łatwiejsze, gdybym zmienił projekt teraz, zanim projekt zostanie upubliczniony, a nie później, w którym musiałbym przez chwilę obsługiwać dwie jego wersje.
  • Chcę wspierać najlepsze praktyki i jeśli przestrzenie nazw staną się najlepszą praktyką dla PHP, mój projekt powinien z nich skorzystać.

Z tego co mogę powiedzieć, musisz wybrać jedną lub drugą drogę; nie możesz zrobić obu. Czy są jakieś punkty, których nie wziąłem pod uwagę? Czy są jakieś obiektywne znaki (proszę nie flamewars), które wskazują w kierunku przestrzeni nazw i stają się profesjonalnym standardem dla PHP? Byłbym wdzięczny za wszelkie spostrzeżenia i zasoby, którymi chciałbyś się podzielić, ponieważ muszę wkrótce podjąć decyzję.

Odpowiedzi:


5

Dwa znaki, że przestrzenie nazw w PHP pozostaną:

  1. Schemat nazewnictwa PEAR został porzucony na rzecz przestrzeni nazw w PEAR2 .
  2. Jednym z deklarowanych celów Zend Framework 2.0 jest bycie przykładem użycia PHP 5.3 , między innymi poprzez pełne wykorzystanie przestrzeni nazw. Uważam to za wyraźną wskazówkę, że Zend jest w pełni oddany przestrzeniom nazw i będzie nadal je wspierał i ewoluował (mam nadzieję, że będzie lepszy).

W pełni się z tobą zgadzam, że brakuje co najmniej bieżącej implementacji przestrzeni nazw, ale twoje argumenty przeciwko ich użyciu nie są tak solidne. Nawet w obecnej formie przestrzenie nazw zapewniają:

  • Lepsza organizacja kodu,
  • Unikanie kolizji nazw,
  • Kontekst dla klas, funkcji i stałych.

Należy pamiętać, że większość argumentów przeciwko przestrzeniom nazw PHP jest w porównaniu do implementacji w innych językach, a nie przeciwko ich faktycznym zaletom jako funkcji.


+1 za linki. Czy możesz rozwinąć lepszą organizację kodu i punkty kontekstu? Trochę trudno mi zrozumieć, w jaki sposób zapewnia lepszą organizację kodu. Wygląda na to, że większość projektów będzie trzymać się klasy 1: 1, aby struktura plików pogrupowana w katalogach logicznych była taka sama jak w schemacie nazewnictwa PEAR. Nawet ZF2 wygląda na to, że w większości przypadków używa tego samego katalogu i struktur plików, ale właśnie teraz z przestrzeniami nazw. Jest inaczej, ale niekoniecznie widzę, jak jest lepiej lub lepiej zorganizowany niż dobrze nazwane katalogi i pliki.
VirtuosiMedia,

Mam również problem z punktem kontekstowym. Jeśli już, to wygląda na to, że przestrzenie nazw usuwają kontekst, aby mieć bardziej zwięzły styl kodowania niż dodawanie kontekstu. Na przykład, jeśli utworzę nową klasę głęboko w pliku, muszę teraz znaleźć miejsce, w którym zadeklarowano przestrzeń nazw, aby dowiedzieć się, którą to klasę, zamiast mieć ją od razu widoczną z nazwy klasy. O ile mi czegoś nie brakuje, wydaje się, że przestrzenie nazw są mniej szczegółowe, ale kosztem przejrzystości.
VirtuosiMedia,

@VirtuosiMedia PEAR i stare schematy nazewnictwa ZF emulują przestrzenie nazw, więc moje trzy punkty są nieco dla nich prawdziwe. Próbuję wskazać, że jeśli te punkty są prawdziwe w obecnej implementacji przestrzeni nazw PHP, to ich małe snafusy nie wystarczą, aby ich nie używać. Dzięki lepszej organizacji kodu mam na myśli głównie pliki, przyjmując rozsądną i logiczną strukturę i hierarchię dla swoich klas, co jest oczywiście wykonalne bez przestrzeni nazw. Ale przestrzenie nazw (i schematy, które je emulują ) są funkcją, która pomaga osiągnąć wszystkie trzy punkty naraz.
yannis,

Gotcha Dziękuję za wyjaśnienie. Czy widzisz znaczącą przewagę rzeczywistych przestrzeni nazw nad emulowanymi przestrzeniami nazw?
VirtuosiMedia,

1
@VirtuosiMedia Wszystkie punkty za korzystanie z przestrzeni nazw podanych w pytaniu są ważne. Dodam do tego, że przestrzenie nazw PHP pomagają kodowi wydawać się nieco bardziej naturalny dla programistów z różnych środowisk, co może być nieocenione w dużym projekcie. Nie ma też standardu dla emulowanych przestrzeni nazw, na pewno większość z nich jest mniej więcej taka sama, ale użycie rzeczywistych przestrzeni nazw gwarantuje, że wszyscy używają tego samego schematu. BTW, jest tam przestrzeń nazw , której możesz użyć, aby uprościć kod.
yannis,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.