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?

Namespace, composer, psr-4

No, OK, czyli cała ta zabawa jest po to by być kompatybilnym z ps-4 i móc sobie ściągnąć jakiś pakiet?

Nie, chodzi o przykład autoloadera opartego o composer

Ogólnie autoloading oparty o namespace gdzie jest to struktura katalogów. Dzięki temu wiesz gdzie szukać danej klasy

No dobra, a jakbym teoretycznie chciał stworzyć framework, który nie ma w założeniu być kompatybilny z composerem i psr-4, tylko miałby własny mechanizm autoloadingu (sam wiedziałby gdzie szukać) to mogę wszystko zamknąć w jednym namespace o nazwie myFramework ? To ma sens?

Możesz, dzięki temu masz odseparowanie swoich bibliotek od np. zew. Przykładem może być klasa View. Może ona być w Twoim frameworku i w zew. bibliotece. Wybierasz sobie którą chcesz. Nie ma konfliktu.

Tu masz bardzo fajnie o namespace: http://ttomczyk.pl/182/php-5-3

Dzięki!

Use nie musisz wpisywać, jeżeli używasz jakiegoś normalnego edytora, podczas wybierania klasy z listy dostępnych klas, samo ci dodaje use wraz z przestrzenią do pliku. Ostatni raz ręcznie musiałem tego używać, kiedy korzystałem z edytora który nie wspierał wszystkich ficzerów z php 5.3

@by_ikar: Dzięki, używam netbeansa, zrobię update bo to b. stara wersja i zobaczę jak to chodzi.

Ale tak czytam to: https://github.com/php-fig/fig-standards/bl...4-autoloader.md oraz przykład autoloadera: https://github.com/php-fig/fig-standards/bl...der-examples.md

I czy dobrze myślę, że ludzie sobie wpadli na pomysł jak zorganizować kod (w katalogach w relacji z namespaces), napisać do tego autoloader i to wszystko ubrali w psr-4?

Nie wiem czemu ale jakoś to do mnie nie przemawia. W pewnym prostym frameworku, który napisałem, był właśnie jeden namespace, i gdy autoload chciał odnaleźć daną klasę, to szukał w aktualnym folderze, potem w folderze modules, potem w podfolderach modules i to było zajebiście wygodne... Zresztą podobnie działa node.js. Tak coś mi intuicja podpowiada, że ten cały psr-4 jest niepraktyczny:)

Czy dobrze w ogóle zrozumiałem motywy i działanie psr-4?

No widzisz, Ty szukałeś w n katalogach a mając dost. do namespace np.

Frameworkd\Bundle\Feature

szukasz klasy x w folderze Bundle->Feature i tam musi być.

To zrezygnuj z psr-4 i zastosuj psr-3

Dzięki już łapię Tylko taka ostatnia rzecz - to nie ma za bardzo sensu bez takiego composer'a prawda? Tzn. ma, ale trzeba by było ściągnąć, zobaczyć w jakim namespace jest umieszczony i wtedy wrzucić do odpowiedniego katalogu tak?


Ehh, pół dokumentu przeczytałem by zrozumieć co ma logowanie do namespaces:)

!*! psr-3 głównie traktuje o interfejsie klasy logowania błędów

@up masz na myśli bibliotekę pobraną z composera?
Jeżeli tak to właśnie używanie composera jako modułu autoloadera jest cholernie wygodne Podajesz tylko deklarację namespace w pliku composer.json aplikujesz to wszystko do aplikacji i działa.

Dzięki!

- 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

- do mnie też

Kiedyś się pisało folder_folder_klasa, gdzie 100 razy musieliśmy to pisać, teraz mamy \folder\folder\klasa gdzie możemy dać use lub bawić się tak samo jak kiedyś z '_'.

Namespaces nie są takie złe, mają po prostu swoje wady. Rozwiązują problem kolizji nazw kosztem zwiększenia złożoności kodu.

Zgodzę się z Pilsener, że czasem utrudniają czytanie kodu. Czasem jest to problematyczne by zorientować się i zapamiętać z jakiego namespace pochodzi klasa, szczególnie, gdy jest ich dużo w jednym pliku. Kiedyś pisało się A_B_C i to jednoznacznie i prosto identyfikowało klasę, a teraz używanie samej nazwy C często nie wystarcza, więc trzeba albo skakać do sekcji use i sprawdzać, albo nazywać nazw w stylu A\AB\ABC, albo używać aliasów nawet, jak nie potrzeba, by zwiększyć czytelność: A\B\C as ABC. I faktycznie, nigdy wcześniej nie trafiła mi się kolizja nazw przy nazywaniu A_B_C za to obecnie dość często trafiają się identyczne nazwy klas z użyciem namespace: A\B\C, D\C itp.

Namespaces są całkiem wygodne, gdy używamy ich wewnątrz jakiegoś pakietu/biblioteki - poruszamy się ciągle w tej samej, zamkniętej całości, we wspólnym namespace, używane nazwy są krótsze i pisząc dany fragment oprogramowania autor i tak pamięta całą strukturę plików, wie czego dotyczą używane nazwy, i jego kod jest dla niego czytelny i zrozumiały. Tylko mniej fajne to może potem być dla innego programisty, który używa danej biblioteki.

Poza tym, konieczność pisania instrukcji use na początku klasy przypomina mi includowanie plików poprzez require_once - bardzo tego nie lubię, od czego w końcu jest autoloader? No i przejrzystość kodu czasem siada.

Nawet jak nie ma kolizji nazw końcowych, to po samych tych nazwach klas i interfejsów trudno się czasami zorientować, z jakiego namespace pochodzą, szczególnie gdy jest 30 usów na początku z 10 różnych namespaces...

Ale i tak jesteśmy w najbliższej przyszłości skazani na przestrzenie nazw, więc jak komuś się nie podoba, to pozostaje się przyzwyczaić

@Pyton_000 - ale w praktyce jest tak że PSR-4, różni się tylko od PSR-3 ładowaniem klas i tylko to miałem na myśli, bo i tak w większości przypadków używając PSR-3, używa się wcześniejszych, więc nie ma znaczenia jaką liczbę wpiszemy. Choć uważam że powstanie PSR-4 było błędem i znakiem, że nawet mała grupa ludzi ma w swoich szeregach maruderów.

@Pilsener - świetna poprawa humoru z rana, dzięki


Chyba nie bardzo zrozumiałeś działanie przestrzeni nazw i autoloadera. Poza tym kto Wam każe pisać "use" na początku pliku? To nie jest wymagane przy używaniu przestrzeni nazw.

Racja. Use nie jest wymagane. Nie ma sensu pisać


tylko dla tego że 1 raz użyjemy metody która wywodzi się z tej przestrzeni. Można ją dołączyć do nazwy klasy.
User raczej stosuje się jeżeli używamy wiele razy tej samej metody dzięki nie zaciemniamy kodu poniżej.

Generalnie autloader PSR-3 to tak na prawde autloader z PSR-0, a PSR-4 to już inna koncepcja.

Dlaczego cały czas piszecie o PSR-3 jako o czymś co ma związek z automatycznym ładowaniem. Możecie się podzielić Waszym źródłem?
Na oficjalnej stronie php-fig PSR-3 traktuje o interfejsie logowanie wiadomości.

@up - To bez znaczenia. Przyjętą zasadą jest samo PSR, nie rozdziela się tego na 1,2,3 za wyjątkiem 4 . Napisałem PSR-3, bo chodziło o wcześniejsze podejście ludzi którzy nad tym siedzieli.

!*! o czym Ty bredzisz? Poprosiłem o źródło tych wymysłów a nie wypisywanie nowych.

@up oczym Ty bredzisz

Też chciałbym wiedzieć

Dobrze, postaram się od początku:





Na stronie php-fig.org z której czerpię wiedzę na temat PSR znajduje się lista zaakceptowanych standardów. Dla mnie są to osobne rekomendacje, ta o numerze trzecim dotyczy interfejsu logowania, a o numerze 4 ulepszonego automatycznego ładowania. W związku z tym nie rozumiem, jak można stosować 3 i 4 standard zamiennie, to nie są przecież rewizje tego samego dokumentu. Pierwszy raz czytam, że się tego nie rozdziela (a sam rozdzielasz i wyłączasz z tego zbioru dokument 4).

Być może jestem w błędzie, dlatego prosiłem o źródło Waszej wiedzy.

Jeszcze nie było konieczności.

Może to, że pomagają utrzymać porządek w strukturze projektu, nie jest aż tak ważne, żeby uznać za rzeczywistą potrzebę
Ale kilka razy pomogły mi w zamockowaniu globalnych funkcji php w unit testach - i tutaj już ich użycie BARDZO ułatwiło mi osiągnięcie celu.

Tak, PSR od 0 do 4 jest zbiorem standardów niezależnych od siebie. Przynajmniej w teorii, ponieważ w praktyce używa się ich łącznie, mało które firmy czy projekty są pisane z użyciem tylko poszczególnych wersji PSR, co jest w zasadzie głupotą, ponieważ nie używa się standardu w jednym miejscu, żeby w innym zrobić burdel.

Rozdzieliłem PSR-0,3 od 4 ponieważ 4 koliduje ze wcześniejszym podejściem, nie połączysz jej z PSR-0 dlatego grupa która te standardy tworzy, zaprzeczyła sama sobie o trzymaniu się kompatybilności wstecznej.

PSR dzieli się obecnie na 4 grupy.

PSR-0 - które jest standardem autoloadingu
PSR-1 i 2 - standard "pisania" kodu
PSR-3 - Globalny Interfejs Log
PSR-4 - Kolejny standard autoloadingu.

Co za tym idzie możemy używać PSR-3 a nie reszty, możemy 1-2 i 4, możemy 0 i 3.
O żadnej kompatybilności tutaj nie możemy mówić poza 1 i 2 które są zależne od siebie w stecz.

Czy potrzebowaliśmy? Pewnie nie. Tak samo jak nie potrzebowaliśmy autoloadingu, SPLa, coraz sensowniejszego OOP czy paru innych rzeczy. Na szczęście jednak PHP się rozwija.

Naprawdę do mnie nie trafia argument, przeciwko przestrzeniom nazw, że kiedyś pisało się A_B_C, a teraz trzeba A\B\C. To nie jest żaden argument. Czy dla Was czytelniejsze jest to: Symfony_HttpFoundation_Request niż to Symfony\HttpFoundation\Request? Poza tym, każde szanujące się IDE wspiera w stopniu dobrym namespaces (upada drugi "argument" - rozwlekanie dokumentu blokiem use - chyba w każdym IDE można ustawić domyślne zachowanie bloku). Poza tym, komentarze też rozwlekają plik.

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..

To działa także w drugą stronę. Co za różnica, czy napiszę A\B\C czy A_B_C. Liczba znaków czy czytelność obu jest dokładnie taka sama, a chyba nawet A_B_C jest dla mnie nieco czytelniejsze.



Oczywiście, że nie jest wymagane, ale czym różni się używanie w kodzie tasiemców A_B_C_D od A\B\C\D? Jedynie zamianą znaku "_" na "\".

Jesteś tego pewien? W PHP możesz zrobić use A_B_C as C nawet w "starym" kodzie.
A zabawne jest też używanie tych całych namespaceów w połączeniu z SM. Z jednej strony edytor, podpowiadanie itp z drugiej ponowne zapisywanie klas jako stringi "Moj\Super\Namespace".

A poza tym dawno temu PorneL wypunktował błędy https://pornel.net/phpns/pl

Ja tam wolę czystość i przejrzystość kodu, dlatego mam:

[PHP] pobierz, plaintext 
use Symfony\HttpFoundation\Response;
 
$response = new Response();
[PHP] pobierz, plaintext 

Jeśli wolisz pisać za każdym razem A_B_C to ok, o gustach się nie dyskutuje, ale nie jest to czytelniejsze.

Naprawdę nieraz community PHP mnie zadziwia, niektórzy najchętniej by zostali przy funkcjach i potworkach typu CI czy stary Cake.

Niekoniecznie, zawsze możesz skorzystać ze stałej *::class.

- ona jest bez sensu, ale:
- nawet najlepiej napisana klasa z czasem wymaga refaktoryzacji (a ta majta na ostatnim wymionie bo w typowej firmie nie ma czasu nawet na zakodowanie połowy tego, co biznes chce)
- edytor nic nie robi sam, trzeba najczęściej coś kliknąć, użyć myszy a może i mózgu (by wybrać z listy właściwą klasę)
- i nie piszę kodu sam, projektów jest wiele a nierzadko też wiele zespołów i wiem, że jeśli popełnienie błędu jest możliwe to każdy prędzej czy później go popełni

- ja to wiem doskonale, ale rozchodzi się o to, że COŚ trzeba zrobić - np. pomyśleć chwilę (co boli) - a ja może wolałbym tą chwilę pomyśleć o dziewczynie albo siorbnąć łyka inki i nic nie robiąc osiągnąć taki sam efekt

- jak wyżej, co z tego jak trzeba jednak najeżdżać na te nazwy, to ja już wolę najeżdżać na nejmspejsy

- pisałem o zend 1 vs symfony 2, pierwszy lepszy link: http://symfony-docs.pl/cookbook/bundles/best_practices.html (ale czy te wszystkie praktyki są takie debeściarskie czy raczej niecne?) I use nie skraca de facto nazwy klasy (tylko jej zapis w miejscu użycia rozbijając nazwę klasy na dwie części) - nazwa klasy jest taka, jaką zwraca funkcja get_class (zbindowana u mnie od czasu wynalezienia ekstrakcji fabryki obiektów) i taka, jaka wynika ze struktury folderów + nazwy pliku z klasą. Przecież wiem, że w folderze "controller" są kontrolery, po co każda klasa ma się nazywać ..._controller_userController a plik xController.php? A może twórcy symfony używali notatnika?

- nie zgodzę się. Właśnie początkujący rzucają się na te wszystkie najnowsze wynalazki by pokazać, jacy to są zaj... Starzy wiedzą doskonale, że każdy "usprawniacz" to wada w postaci dodatkowej komplikacji, co wydłuża czas projektu i zwiększa liczbę błędów - dlatego jak ktoś chce dołączyć do projektu np. composera to powinien mieć chyba jakieś argumenty za poza "przeskoczmy schodek, nie bądźmy wapniakami!"

I ja chętnie tych argumentów "za" posłucham - poza pewnym ułatwieniem unit testów są jakieś inne WYMIERNE zalety? Poza tym każdy powinien zdawać sobie sprawę z wad jak i zalet rozwiązań, których używa i robić te wszystkie straszne rzeczy świadomie

I żeby nie było - nie jestem przeciwnikiem ani zwolennikiem (możliwe, że umiarkowanym sceptykiem), kodziło się strukturalnie, pseudo-obiektowo w PHP 4, prawie obiektowo w PHP 5 a teraz wstrzykuje się traity adnotacją i też nie działa.

Na co jutro sobie ponarzekam? Może będzie refleksja nad refleksją? Się zobaczy

@Pilsener , mam podobnie jak Ty ; )

Wiesz, zgadzam się, że w tak prostym, trywialnym przykładzie, jak ten, który podałeś, łatwiej, lepiej i przyjemniej jest użyć namespace i use. Problem w tym, że w praktyce nie rzadko człowiek trafia na klasy, które mają po 2000+ linii kodu, w których jest 20+ use i jak nie znasz takiego kodu, a musisz go przejrzeć, zrozumieć, nanieść poprawki, to przeglądanie tego jest zwyczajnie utrudnione, bo gdzieś tam w linii 893 $response = new Response() nić Ci nie powie, póki nie skoczysz do use i nie sprawdzisz, co to za Response. Owszem, IDE pomagają, ale:

1) co chwilę trzeba najeżdżać myszką nad nazwę klasy i czytać skąd pochodzi (aż do poznania i zapamiętania kodu);

2) uważam, że trochę głupie jest uzależnianie się od IDE z podpowiedziami, żeby wygodnie przeczytać i zrozumieć kod. Kod powinien być tak napisany, aby można go było łatwo przeczytać i zrozumieć po wydrukowaniu.

I żeby nie było - lubię jednoczłonowe nazwy (w powyższym przykładzie użyłbym aliasa HttpResponse, bo jest bardziej zrozumiały), ale czy jestem zachwycony namespaces w PHP? Nie, to tylko taki ficzer żadna rewelacja. Na dodatek preferuję składnię importu pakietów z kropką jak w Javie, a PHPowe use \d\s\f\g zwyczajnie mi się nie podoba, ale cóż z tego... Jest jak jest, nie ma co narzekać, i tak musimy korzystać z tego, co dostępne

Po wypowiedzi mojego przedmówcy, teraz rozumiem o co cały ten szum z przestrzenią nazw. Macie racje, mnie też wkurza to, że jak otwieram plik PHP, to jest w nim naciepane znakiem dolara i tym, że jest tak kolorowo, a sam plik nie wie czego od niego chce i jakie są moje myśli. Jest to skandaliczne podejście narzędzia do programisty i uważam że cały PHPTeam poległ w tej kwestii.
Wyrażam też głębokie zaniepokojenie zaistniałą sytuacją, jak również liczę na głębokie sankcje, zarówno nałożone na zespół PHP jak i wszystkie Nasze otwierane pliki.

A czy nie korzystając z namespace nie musisz dużego kodu analizować? Też musisz.


Ale czemu uzależnione? Przecież możesz sobie spokojnie i bez problemu przeczytać kod nawet w Notepad++. 20 linii use to aż taki problem?


No bo to jest tylko ficzer i on nie ma dupy urywać

PS. Też wolałbym z kropką.

Laravel 4.3 będzie "nejmspejsował" nawet kontrolery więc faktycznie "namespace all the things"

Namespace'y to krok naprzód. Są bardziej elastyczne od stosowania nazw klas o określonej strukturze. Nie rozumiem tego wątku, trzeba tak samo pamiętać o przestrzeni nazw jak o całej nazwie klasy w przypadku niestosowania jej. Ja używam namespace'ów, bo je po prostu lubię i w dużych projektach mają sens.

Refaktoryzacje w łatwy sposób przeprowadzić na poziomie edytora. Ludzie, poważnie, zatrzymaliście się na notatniku? Edytor może robić sam, wystarczy że odpowiednio go ustawisz. TO NIE JEST NOTATNIK. Do pisania w grupie używa się wersjonowania kodu git/svn i tam każdą zmianę łatwo wyłapać i cofnąć..


Symfony to nie przestrzenie nazw, a same nazewnictwo kontrolerów możesz w łatwy sposób samemu zmienić. Nie wiem zupełnie jak to się odnosi do namespaców samych w sobie. Użyłeś argumentu który nijak nie odnosi się do przestrzeni nazw samej w sobie. Porównałeś jeden framework z drugim, co jest bezsensu.


Jeżeli według ciebie każdy feature to wada w postaci dodatkowej komplikacji.. to lepiej żebyś zastanowił się jeszcze raz nad swoimi argumentami. Napisałem że albo świeżacy, albo sztywniacy którzy się zatrzymali w początkach php5. No a ty niejako potwierdziłeś to co napisałem.

Jeszcze tylko powiedz z jakiego edytora korzystasz i wszystko będzie jasne

Nie ważne Jaki edytor, ważne Jak się nim posługujemy. Oczywiście notatnik odpada w przebiegach bo nie posiada żadnej funkcjonalności
Ja używam Sublime Text. Ostatnio nawet próbowałem przenieść się na Storma ale jakoś mi to nie wychodzi. Pomimo jego wielu zalet nie chce ze mną współpracować
Uważam że każdy pisze w czym chce. Nawet VIM jest bardzo potężny i nie ujmuje najlepszym IDE.

Ludzie, o co te kłótnie i święte oburzenie co niektórych strażników jedynie słusznych namespace'ów? Jedni lubią, inni nie lubią te namespace'y. Nie hejtujcie.

Pytanie było: "czy kiedykolwiek, w praktyce, potrzebowaliście namespaców?". Pozwólcie wyrazić każdemu swoje zdanie dlaczego, i tyle. To samo w sobie jest ciekawe. Kiedyś nie potrzebowałem i dało się bez nich programować, żaden projekt nie upadł z powodu braku namespeców Teraz są i zwykle stosuję - ale czy są faktycznie niezbędne? Nie . Więc nie mam ciśnienia na ich stosowanie. Pracuję teraz też przy takim projekcie, w którym nie używamy namespaców, bo taki projekt; od początku w nim namespaces nie było i nie ma. I nie ma z tym żadnego problemu.

Jedni je stosują bo tak się teraz robi i jest to trendy, inni bo mają z tego korzyść i widzą w tym jakąś wartość, a inni nie stosują bo nie potrzebują. Namespaces nie są potrzebne do programowania. Czy są użyteczne? Oczywiście, że tak, ale... w małych, jednorodnych projektach (szczególnie prywatnych) zwykle są zwyczajnie zbędne - ich wprowadzenie nic, ale to kompletnie nic, nie wnosi - nie ma z tego żadnej wartości dodanej do projektu. Co innego jeśli skomplikowanie tworzonego oprogramowania rośnie, lub robi się coś udostępnianego publicznie - obecnie standardem jest wypuścić to we własnej przestrzeni nazw Wiadomo

Ale rozmawiajmy na athumenty rzeczowe, ok? A niektórzy tutaj po prostu zdają się argumentować jakimiś dziwnymi teoriami.

Tutaj nie rozchodzi się o to czy ty to lubisz czy nie. W wielu innych poważnych językach przestrzenie nazw istniały od samego początku, i nic poza przestrzeniami nie ma. Więc rzucenie frazesem "jedni je lubią, inni nie lubią" jest całkowicie nie namiejscu. Przestrzenie nazw powstały po to żeby móc: lepiej organizować kod, nie martwić się o konflikt nazw, kontrolować zależności a dzięki PSR struktura katalogów czy nazewnictwa klas nie będzie wymyślana w każdym frameworku z osobna. Nie potrzebujesz przestrzeni nazw? Zapewne nie, kiedy tworzysz 2-3 klasy na krzyż. W przypadku dużych projektów, takie rzeczy mają znaczenie. A jeżeli ktoś dzisiaj się pyta o przestrzenie nazw, w momencie kiedy php 5.3 wydano ponad 6 lat temu, to są dwa wyjścia, albo jest nowicjuszem, albo starą wygą co wszędzie jeszcze klepie global. Jedyne o czym można tutaj dywagować, to nie jest fakt istnienia samych przestrzeni nazw (albo klepiemy, albo programujemy), lecz powiedzmy separator do tego użyty (backslash). Czy w innych językach trzeba pisać use? Raczej nie use, ale using, import jak najbardziej. Czy trzeba pisać do każdej przestrzeni? Nie, tak samo jak w innych językach, tylko w php działa to nieco inaczej. Czy w innych językach trzeba pisać N razy import/using ? Tak, jeżeli twoja klasa wymaga tyle zależności z innych przestrzeni to jak najbardziej. Więc jęczenie że trzeba to pisać za każdym razem, jest bardziej brakiem odpowiednich narzędzi które nam to ułatwią, albo zwykłej niewiedzy.

To nie jest coś co można akceptować lub nie, bo gdyby przestrzenie nazw istniały od samego początku, to nie było by takich problemów z nazewnictwem niektórych funkcji, np strstr, str_replace, substr, a mogłoby by to wyglądać tak: str/match, str/replace, str/substring etc. No ale grupka starych wyg/nowicjuszy zawsze będzie narzekać, bo dodadzą im jedną rzecz dodatkową do zapamiętania/nauczenia się..

W PHP nie używałem, w javie i .NET - nie było innej możliwości.

Teraz w PHP też będę używał, szczególnie, jak będę coś robił w ZF2.

Patrząc na ewolucję, jaką przechodzi PHP, jak wpływa na wybory lepszych programistów (ZF1 -> ZF2), wydaje mi się, że nie ma co stawać w poprzek, owszem można napisać wszystko i proceduralnie, można rzeźbić własne frameworki itd, ale gdzie w tym profesjonalizm?

Pieprzyć profesjonalizm, teraz jest moda na bycie alternatywnym i działanie wbrew głównemu nurtowi. A sensownych argumentów przeciwko NS dalej nie ma

Sam sobie przeczysz. W PHP namespaców kiedyś nie było, obecnie są. Tak samo jak są języki bez namespaców. Czy można w nich programować? Tak, można. Czy można w PHP programować bez namespaców? Tak, można. Twierdzenie, że nie można, jest zwyczajną bzdurą. Może to być kwestia wyboru, osobistych preferencji programisty, czy będzie pisał swój kod w PHP z użyciem namespaces, czy bez nich, czy to lubi, czy nie lubi. Dziwne mnie jak można tego nie rozumieć.



To samo napisałem wcześniej; nie wiem, czy mi to tłumaczysz, czy powtarzasz to bo się ze mną zgadzasz? Dla uściślenia: moje stanowisko jest tu wyraźnie określone - uważam, że w wielu (głównie małych - ale gdzie granica?) typowych projektach, tzw. przeciętny programista nie potrzebuje przestrzeni nazw, w takim sensie, że nie ma z nich żadnego wymiernego profitu, może poza zaspokojeniem osobistych preferencji i przekonań tegoż programisty.

Kod można świetnie organizować bez użycia przestrzeni nazw, tak samo jest z ładowaniem zależności, autoloadingiem itp. Namespeces tylko pomagają, ułatwiają w niektórych z tych zagadnień. Nie są niezbędne.



Mylisz się - moje stwierdzenie, że trzeba to pisać za każdym razem, nie jest, jak to pogardliwie określiłeś, jęczeniem, ale prostym stwierdzeniem faktu. Pytanie tylko, czy to rozumiesz. Fakt występuje niezależnie od Twojego czy mojego widzimisię. Inną sprawą jest moja czy Twoja subiektywna opinia, tudzież ocena tego faktu, a z opinią jeden się zgadza a drugi nie. Otóż jeśli Ty uważasz, że to jest naturalne, fajne i jak najbardziej w porządku, że na początku pliku znajduje się xx dyrektyw use, i wcale Ci to nie przeszkadza, to OK - nic mi do tego. Mi natomiast to nieco przeszkadza, i traktuję te sekcje use'ów jako swego rodzaju "zło konieczne" istnienia namespaces, bo lepiej tego do tej pory w tych językach nie wymyślono. Z dokładnie tego samego powodu nie lubię także ładowania klas instrukcjami require. Rzecz gustu, można by rzec

Dyskutować to można nad tym czy użycie namespaców, które wiąże się z takimi a takimi kosztami, a daje takie a takie zyski, sumarycznie się opłaca w danym przypadku. No przepraszam, ale dla mnie ktoś, kto pisze wszystko, każdy, nawet najprostszy, jednoplikowy programik PHP zamknięty w namespace, to prawdopodobnie cierpi na nerwicę natręctw bądź robi to bezmyślnie niczym wyuczony nawyk.

Pytanie zadane na początku było: "czy kiedykolwiek potrzebowaliście namespaców?". Niech każdy za siebie odpowie. Ja nie potrzebowałem, choć raz zdarzyło się, że kilka klas w projekcie miało taki sam pierwszy człon nazwy, co pewna zewnętrzna biblioteka której dołączenie było rozważane - ale problem zniknął sam, bo zapadła decyzja użycia innej biblioteki. Więc muszę szczerze przyznać się, że nie nigdy tak naprawdę nie potrzebowałem przestrzeni nazw, choć to nie jest politycznie poprawne

Chciałbym przypomnieć, że póki w PHP nie było przestrzeni nazw, wszyscy programowali bez przestrzeni nazw. Czy więc były potrzebne? Odpowiedź jest oczywiście tylko jedna: NIE - w sensie takim, że nie jest to element języka, którego istnienie miało by określać możliwość napisania programu. To jest proste i logiczne, czego tu można nie rozumieć?

Może problem w tym, że "potrzebować" ma kilka znaczeń. Drugie znaczenie "potrzebowaliście namespaców" jest takie, że chodzi o to, czy programista chciałby mieć możliwość pisania kodu z użyciem namespaców - bo ma taką zachciankę, bo tak jest w innym języku, bo tak jest modnie, bo tak w szkole uczą, albo tak lubi. I w tym sensie faktycznie można przestrzeni nazw "potrzebować" zawsze.

I wreszcie jest trzecie znaczenie "potrzebować namespaców" - gdy ich zastosowanie ulepszy kod, jego organizację i czytelność, itp. - poddajemy coś ocenie i według przyjętych kryteriów stwierdzamy, że tak lub nie. Ale to już wymaga wysiłku umysłowego i faktycznego zrozumienia tematu.

Mogę sobie też wyobrazić, że ktoś "potrzebuje namespaców" do napisania programu, bo bez nich po prostu nie da się tego oprogramowania napisać - no, nie da się zakodować rozwiązania i koniec - nic, zero, bez wyjścia, kaput. Tylko, że... nie widziałem jeszcze takiego przypadku w realu, aczkolwiek chętnie poznam. Mógłby ktoś podesłać link z jakiegoś case study o takim projekcie w PHP?

Niektórzy tu nie mają żadnych argumentów więc co robią? Wydają osądy i używają różnych epitetów pod adresem adwersarzy, co świadczy tylko o tym, że się nie ma żadnego sensownego zdania w temacie - a wiadomo: jak nie wiadomo co powiedzieć, to najłatwiej zmieszać z błotem, zasugerować, że ta druga osoba to albo nowicjusz, albo jakiś staruszek, który "klepie globale", czy inne takie. To naprawdę śmieszne. Paradoksalnie, to przynajmniej pod jednym względem jest dokładnie odwrotnie, bo to właśnie stary wyga będzie miał doświadczenie, dystans i własny osąd (plus zdrowy rozsądek), których to młodziakom czasem brakuje.