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?

[Pyton_000]

Namespace, composer, psr-4

[konrados]

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?

Ten post edytował konrados 31.08.2014, 10:06:17

[Pyton_000]

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

Ten post edytował Pyton_000 31.08.2014, 10:08:56

[konrados]

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?

[Pyton_000]

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

[konrados]

Dzięki!

[by_ikar]

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

[konrados]

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?

[Pyton_000]

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

[!*!]

Tak coś mi intuicja podpowiada, że ten cały psr-4 jest niepraktyczny:)

To zrezygnuj z psr-4 i zastosuj psr-3 (IMG:style_emoticons/default/wink.gif)

[konrados]

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

Dzięki już łapię(IMG:style_emoticons/default/smile.gif) 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?

To zrezygnuj z psr-4 i zastosuj psr-3 wink.gif

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

[Pyton_000]

!*! psr-3 głównie traktuje o interfejsie klasy logowania błędów (IMG:style_emoticons/default/wink.gif)

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

[konrados]

Dzięki!

[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)

[Spawnm]

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

[irmidjusz]

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 (IMG:style_emoticons/default/tongue.gif) za to obecnie dość często trafiają się identyczne nazwy klas z użyciem namespace: A\B\C, D\C itp. (IMG:style_emoticons/default/tongue.gif)

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? (IMG:style_emoticons/default/wink.gif) 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ć (IMG:style_emoticons/default/tongue.gif)

[!*!]

@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 (IMG:style_emoticons/default/smile.gif)

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.

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.

[Pyton_000]

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

Kod

use Acme\Support

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.

[destroyerr]

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.

[destroyerr]

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

[Pyton_000]

@up oczym Ty bredzisz (IMG:style_emoticons/default/wink.gif)

[!*!]

@up oczym Ty bredzisz (IMG:style_emoticons/default/wink.gif)

Też chciałbym wiedzieć (IMG:style_emoticons/default/wink.gif)

[destroyerr]

Dobrze, postaram się od początku:

To zrezygnuj z psr-4 i zastosuj psr-3

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

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

Generalnie autloader PSR-3 to tak na prawde autloader z PSR-0

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.

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.

[Turson]

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

Jeszcze nie było konieczności.

Ten post edytował Turson 4.09.2014, 13:42:23

[MLukasz]

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

Może to, że pomagają utrzymać porządek w strukturze projektu, nie jest aż tak ważne, żeby uznać za rzeczywistą potrzebę (IMG:style_emoticons/default/wink.gif)
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.

[!*!]

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.

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.

[Pyton_000]

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.

[pedro84]

Jak w pytaniu, czy kiedykolwiek, w praktyce, potrzebowaliście namespaców?

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.

[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

[irmidjusz]

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?

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.

Poza tym kto Wam każe pisać "use" na początku pliku? To nie jest wymagane przy używaniu przestrzeni nazw.

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? (IMG:style_emoticons/default/biggrin.gif) Jedynie zamianą znaku "_" na "\".

[viking]

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

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

Ten post edytował viking 5.09.2014, 08:52:05

[pedro84]

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.

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.

[destroyerr]

z drugiej ponowne zapisywanie klas jako stringi "Moj\Super\Namespace"

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

[Pilsener]

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.

- 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

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

- 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 (IMG:style_emoticons/default/Lkingsmiley.png)

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.

- jak wyżej, co z tego jak trzeba jednak najeżdżać na te nazwy, to ja już wolę najeżdżać na nejmspejsy (IMG:style_emoticons/default/baaasmiley.gif)

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.

- 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? (IMG:style_emoticons/default/nerdsmiley.png)

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

- nie zgodzę się. Właśnie początkujący rzucają się na te wszystkie najnowsze wynalazki by pokazać, jacy to są zaj... (IMG:style_emoticons/default/smile.gif) 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!" (IMG:style_emoticons/default/ohno-smiley.gif)

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 (IMG:style_emoticons/default/smile.gif)

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 (IMG:style_emoticons/default/Lkingsmiley.png)

[gitbejbe]

(IMG:https://i.chzbgr.com/maxW500/7811662080/h6CE34C68/.jpg)

@Pilsener , mam podobnie jak Ty ; )

[irmidjusz]

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.

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 (IMG:style_emoticons/default/wink.gif) ż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... (IMG:style_emoticons/default/tongue.gif) Jest jak jest, nie ma co narzekać, i tak musimy korzystać z tego, co dostępne (IMG:style_emoticons/default/smile.gif)

[!*!]

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.

Ten post edytował !*! 5.09.2014, 07:53:10

[pedro84]

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

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

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.

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

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 (IMG:style_emoticons/default/wink.gif) ż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... (IMG:style_emoticons/default/tongue.gif) Jest jak jest, nie ma co narzekać, i tak musimy korzystać z tego, co dostępne (IMG:style_emoticons/default/smile.gif)

No bo to jest tylko ficzer i on nie ma dupy urywać (IMG:style_emoticons/default/smile.gif)

PS. Też wolałbym z kropką.

[nrm]

Laravel 4.3 będzie "nejmspejsował" nawet kontrolery (IMG:style_emoticons/default/wink.gif) więc faktycznie "namespace all the things" (IMG:style_emoticons/default/wink.gif)

[SmokAnalog]

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.

[by_ikar]

- 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

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

- 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? (IMG:style_emoticons/default/nerdsmiley.png)

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.

- nie zgodzę się. Właśnie początkujący rzucają się na te wszystkie najnowsze wynalazki by pokazać, jacy to są zaj... (IMG:style_emoticons/default/smile.gif) 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!" (IMG:style_emoticons/default/ohno-smiley.gif)

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 (IMG:style_emoticons/default/smile.gif)

[Pyton_000]

Nie ważne Jaki edytor, ważne Jak się nim posługujemy. Oczywiście notatnik odpada w przebiegach bo nie posiada żadnej funkcjonalności (IMG:style_emoticons/default/wink.gif)
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ć (IMG:style_emoticons/default/wink.gif)
Uważam że każdy pisze w czym chce. Nawet VIM jest bardzo potężny i nie ujmuje najlepszym IDE.

Ten post edytował Pyton_000 5.09.2014, 18:31:34

[irmidjusz]

Ludzie, o co te kłótnie i święte oburzenie co niektórych strażników jedynie słusznych namespace'ów? (IMG:style_emoticons/default/biggrin.gif) 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 (IMG:style_emoticons/default/biggrin.gif) Teraz są i zwykle stosuję - ale czy są faktycznie niezbędne? Nie (IMG:style_emoticons/default/smile.gif) . 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 (IMG:style_emoticons/default/tongue.gif) Wiadomo (IMG:style_emoticons/default/smile.gif)

[pedro84]

Ludzie, o co te kłótnie i święte oburzenie co niektórych strażników jedynie słusznych namespace'ów? (IMG:style_emoticons/default/biggrin.gif) Jedni lubią, inni nie lubią te namespace'y. Nie hejtujcie.

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

[by_ikar]

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

[Janusz1200]

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?

[pedro84]

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 (IMG:style_emoticons/default/smile.gif)

[irmidjusz]

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.

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

Nie potrzebujesz przestrzeni nazw? Zapewne nie, kiedy tworzysz 2-3 klasy na krzyż. W przypadku dużych projektów, takie rzeczy mają znaczenie.

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.

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.

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 (IMG:style_emoticons/default/tongue.gif)

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 (IMG:style_emoticons/default/biggrin.gif) 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 (IMG:style_emoticons/default/tongue.gif)

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? (IMG:style_emoticons/default/smile.gif)

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.

[pedro84]

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ć?

Jedna mała uwaga ode mnie, bo męczocy i smutny ten wątek już jest. Niby programiści, niby logiczne myślenie, a większość z Was naprawdę słabo argumentuje.

Kontrargument na Twój, niech będzie, że argument: kiedyś w PHP nie było porządnego OOP. Czy było więc potrzebny? 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ć?

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?

I takiego nie będzie. Tak samo jak aplikacji, której nie dałoby się napisać strukturalnie.

---

Ja naprawdę nie rozumiem już zupełnie skąd ten hejt niektórych na przestrzenie. Widziałem marudzenie na większość ficzerów, standardów, ale żadne nie było tak słąbo argumentowane jak to tutaj. Strach pomyśleć co będzie po wydaniu PHP7...

[by_ikar]

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

Nigdzie nie napisałem że się nie da.. Preferencje to możesz mieć seksualne, to nie jest coś co sobie możesz wybierać, np rodzaj frameworka, to jest jeden ze sposobów które oferuje ci język, na to żebyś mógł łatwiej ogarnąć swój projekt. Rozumiem że komuś to jest niepotrzebne, lub kogoś to przerasta. Dlatego też napisałem że przeciwnicy NS to przeważnie stare wygi, albo początkujący, dla których każda dodatkowa informacja to za dużo wiedzy na zapamiętanie/zrozumienie.

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 (IMG:style_emoticons/default/tongue.gif)

A jak chcesz inaczej dołączać inne klasy/pliki do aktualnego pliku jak nie za pomocą require/include ?

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 (IMG:style_emoticons/default/biggrin.gif) bądź robi to bezmyślnie niczym wyuczony nawyk.

Mhm bo trzymanie się standardów i jakichś wytycznych, to nerwica natręctw. Koszty związane z użyciem namespace, chyba tobie daruje, bo najwidoczniej nigdy nie pracowałeś nad czymś co jest napisane z użyciem przestrzeni nazw. Jeżeli twój jednoplikowy program, w którym założysz że dla czytelności nazwiesz swoje funkcje nazwami, które już występują przykładowo w bibliotece standardowej, to możesz użyć NS aby twój program był taki jak sobie to wymyśliłeś i działał. A ty sam nie musisz zastanawiać się nad refaktoryzacją.

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 (IMG:style_emoticons/default/tongue.gif)

Tak jak myślałem, nigdy nie pracowałeś nad projektem w którym na porządku dziennym używa się NS, ale łatwo jest ci strzelić kilka postów na temat tego że NS to bzdura. Niech zgadnę zend? Kohana? A może jakiś wordpress ?

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ć?

Póki nie było preg_* wszyscy używali ereg które z optymalizacją miało niewiele wspólnego. Czy warto jest używać preg_* skoro wszyscy programowali w ereg i było zajebiście? Zakoduj sobie jedno. Albo klepiesz kod, albo programujesz. Sam sobie odpowiedz na to pytanie. A porównań do nowości wprowadzanych w różnych wersjach php jest dziesiątki.

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.

Mhm, czyli moje argumenty typu co mamy dzięki przestrzenią nazw, co w sumie nawet zacytowałeś, to już nie jest argument..? I powiedz, jak tutaj nie używać epitetów? Powiem to otwarcie, bo widzę takie skróty myślowe są odbierane jako złośliwy komentarz. Jeżeli chcesz się dzisiaj rozwijać i nie siedzieć do końca życia nad wordpressem, albo frameworkami ze wsteczną kompatybilnością php5.2, to każdy twój negatywny komentarz na temat przestrzeni nazw (z wyjątkiem separatora) automatycznie stawia cię w jednym z dwóch miejsc. Albo siedzisz na jakimś starym FW, albo klepiesz wtyczki do wordpressa (czy czegoś podobnego). No tak, bo tylko stary wyga może wydawać jedyne słuszne osądy (IMG:style_emoticons/default/biggrin.gif)

A miał się ten php rozwijać, miał iść do przodu, ale przez skostniałych klepaczy, wciąż na hostingach pożądany jest php w wersji 5.2.. Oby tak dalej, dzięki takiemu podejściu, ludzie którzy mają aspiracje więcej zarabiają.

Ten post edytował by_ikar 7.09.2014, 10:21:33

[irmidjusz]

Hehe, dobra chłopaki, ubawiłem się tymi komentarzami co do mnie (IMG:style_emoticons/default/smile.gif) Zamykamy temat.

[!*!]

(IMG:http://s30.postimg.org/639tjzsxd/3898460_8864152835.gif)

Wygląda na to, że temat można zamknąć klasycznym: są programiści i są "programiści".

[pedro84]

Wygląda na to, że temat można zamknąć klasycznym: są programiści i są "programiści".

Zdecydowanie. A jak braknie argumentów, to piszemy, że się dobrze bawimy i zamykamy temat (IMG:style_emoticons/default/biggrin.gif)

[by_ikar]

Taa przecież include_path wystarczy użyć raz, bez żadnego impaktu na pozostałe pliki! Na co komu przestrzenie nazw!

To że include_path mieli dyskiem za każdym razem kiedy próbujesz odczytać plik, to już jest najmniej istotne.. Ważne że nie trzeba w notatniku ręcznie dopisywać use na początku pliku.. Załamka totalna.

[!*!]

Zdecydowanie. A jak braknie argumentów, to piszemy, że się dobrze bawimy i zamykamy temat (IMG:style_emoticons/default/biggrin.gif)

Szczerze mówiąc to już się pogubiłem jakich Ty argumentów szukasz, z tematu zrobił się niezły burdel, już dawno takiego tu nie było. Moim zdaniem @by_ikar dobrze podsumował całość i również się pod tym podpisuję.

[Pilsener]

Argumentów nie brak i krytyków namespace w PHP też, tutaj znalazłem stary, acz ciekawy wpis:
https://pornel.net/phpns/pl

Po prostu jakoś mi brakuje achów i ochów na temat zalet używania przestrzeni nazw w PHP - po tego typu ficzerach oczekiwałbym jednoznacznego entuzjazmu i euforii (IMG:style_emoticons/default/wink.gif)

Paradoksalnie zatoczyliśmy koło: zamiast stada topornych include/require jak w czasach PHP 4 mamy dziś poemat wdzięcznych usów - ale ważne Panowie, że nie rdzewiejemy i nie gnuśniejemy, roboty jest od metra i tak dalej (IMG:style_emoticons/default/Lkingsmiley.png)

[pedro84]

Argumentów nie brak i krytyków namespace w PHP też, tutaj znalazłem stary, acz ciekawy wpis:
https://pornel.net/phpns/pl

Rzeczowe argumenty, aczkolwiek nie wszystkie, których niektórym w tym wątku brakowało.

Mała uwaga, PHP jako język ogólnie jest dosyć niedorobiony i z tym musimy się:
a) pogodzić
(IMG:style_emoticons/default/cool.gif) programować w innym.

Ja tam bardzo ubolewam, że w PHP7 nie ma szans (i chyba nigdy nie będzie) na poprawę i ujednolicenie API.

[by_ikar]

https://pornel.net/phpns/pl -

Nie da się importować całych przestrzeni

Pośrednio da się to "rozwiązać":

[PHP] pobierz, plaintext 
use Foo\Driver;
 
$a = new Driver\Apc();
$b = new Driver\xCache();
[PHP] pobierz, plaintext 

Zapomniane importy/aliasy

Odnośnie edyotrów które podświetlają nieużywany kod..

Sporo z pozostałych problemów wynika z kompatybilności wstecznej.. Jeżeli teraz ludzie narzekają na NS, nawet w takim stanie w jakim jest, to co by było gdyby przebudowali php i nie byłoby wstecznej kompatybilności? No patrząc na tych wielbicieli include_path i innych zabytków, to brak wstecznej kompatybilności byłby zabójczy dla php. I tak też się stało z php6, które było klapą.

Niech sobie te przestrzenie nazw będą jakie są, ważne że spełniają swoje kilka zadań, nawet z kilkoma problemami, ale spełniają. Ktoś kto nie docenia PSR-0 czy PSR-4 IMO jeżeli nie przemyśli swojej drogi rozwoju, to może za kilka lat obudzić się z ręką w nocniku, w jakiejś firmie krzak, klepiąc wtyczki do zabytkowych wersji wordpressa. Rozumiem że ktoś to lubi, spoko i do tego ludzie są potrzebni. No ale tacy ludzie nie mogą decydować, czy też IMO wypowiadać się na temat przyszłości tego języka bo to jest bezsensu..

[Turson]

Laravel 4.3 będzie "nejmspejsował" nawet kontrolery (IMG:style_emoticons/default/wink.gif) więc faktycznie "namespace all the things" (IMG:style_emoticons/default/wink.gif)

czemu "nawet"? To namespace dla kontrolerów jest jakaś abstrakcją?

[Crozin]

Lepiej dać przykład - nieduży (!) projekt, wykorzystujący kilka zew. bibliotek - 475 klas, które mają taką samą końcówkę nazwy z czego rekordzistka powtarza się 40 razy:

Kod

Array
(
    [Method] => 2
    [FirePHPHandler] => 2
    [Generator] => 2
    [FileLocatorInterface] => 2
    [Formatter] => 2
    [HandlerInterface] => 2
    [RedisHandler] => 2
    [ReadOnlyResource] => 2
    [ServiceException] => 2
    [WebProcessor] => 2
    [SwiftMailerHandler] => 2
    [TestKernel] => 2
    [MainConfiguration] => 2
    [RegisterEventListenersAndSubscribersPass] => 2
    ...
    wycięte - zbyt długa treść postu
    ...
    [TraceableEventDispatcher] => 2
    [RegisterListenersPass] => 2
    [FormBuilderInterface] => 2
    [Regex] => 2
    [Glob] => 2
    [FileNotFoundException] => 2
    [Hour1200Transformer] => 2
    [Hour1201Transformer] => 2
    [PropertyPath] => 2
    [TokenNotFoundException] => 2
    [MissingOptionsException] => 2
    [InvalidOptionsException] => 2
    [NotImplementedException] => 2
    [Optional] => 2
    [ExecutionContext] => 2
    [PropertyMetadataInterface] => 2
    [MetadataInterface] => 2
    [FilesLoader] => 2
    [ExecutionContextInterface] => 2
    [MethodNotImplementedException] => 2
    [MethodArgumentValueNotImplementedException] => 2
    [MinuteTransformer] => 2
    [MonthTransformer] => 2
    [HourTransformer] => 2
    [Hour2401Transformer] => 2
    [Hour2400Transformer] => 2
    [QuarterTransformer] => 2
    [SecondTransformer] => 2
    [MethodArgumentNotImplementedException] => 2
    [YearTransformer] => 2
    [Transformer] => 2
    [TimeZoneTransformer] => 2
    [FlattenException] => 2
    [FatalErrorException] => 2
    [TextDescriptor] => 2
    [XmlDescriptor] => 2
    [MarkdownDescriptor] => 2
    [JsonDescriptor] => 2
    [Descriptor] => 2
    [DescriptorHelper] => 2
    [RouterDataCollector] => 2
    [DelegatingLoader] => 2
    [HttpCache] => 2
    [TestSessionListener] => 2
    [SessionListener] => 2
    [TemplatingPass] => 2
    [TwigEngine] => 2
    [Pivot] => 2
    [DocumentInterface] => 2
    [MultiQuery] => 2
    [EdisMax] => 2
    [DistributedSearch] => 2
    [LocaleListener] => 2
    [CollectionToArrayTransformer] => 2
    [StubTranslator] => 2
    [Scope] => 2
    [LintCommand] => 2
    [MessageDataCollector] => 2
    [Router] => 2
    [PathPackage] => 2
    [InvalidConfigurationException] => 2
    [NodeInterface] => 2
    [VariableNodeDefinition] => 2
    [NodeBuilder] => 2
    [ArrayNode] => 2
    [HelperInterface] => 2
    [TokenStream] => 2
    [ExceptionHandler] => 2
    [TranslatorInterface] => 2
    [ExtensionInterface] => 2
    [AbstractExtension] => 2
    [DebugClassLoader] => 2
    [WebProfilerExtension] => 2
    [TemplateNameParser] => 2
    [PhpEngine] => 2
    [EngineInterface] => 2
    [DelegatingEngine] => 2
    [TemplateReference] => 2
    [ObjectsProvider] => 2
    [ExceptionController] => 2
    [DebugCommand] => 2
    [FirewallMap] => 2
    [ConstraintValidatorFactory] => 2
    [ServerException] => 2
    [ResponseParserInterface] => 2
    [YamlDriver] => 2
    [XmlDriver] => 2
    [DriverChain] => 2
    [SimpleObjectHydrator] => 2
    [OrderBy] => 2
    [PreFlush] => 2
    [RequestException] => 2
    [Literal] => 2
    [Join] => 2
    [ObjectHydrator] => 2
    [SequenceGenerator] => 2
    [ImportCommand] => 2
    [AbstractVisitor] => 2
    [View] => 2
    [Sequence] => 2
    [DateTimeType] => 2
    [DateType] => 2
    [TimeType] => 2
    [TextType] => 2
    [IntegerType] => 2
    [Base] => 2
    [LimitSubqueryOutputWalker] => 2
    [ComponentController] => 2
    [ReviewController] => 2
    [ProfileController] => 2
    [FeedbackController] => 2
    [LoadAccountData] => 2
    [LoadSurveyData] => 2
    [Address] => 2
    [Traceable] => 2
    [TypeType] => 2
    [SecurityEvents] => 2
    [SignerInterface] => 2
    [DumpCommand] => 2
    [SchemaValidator] => 2
    [Paginator] => 2
    [Controller] => 2
    [JsonResponse] => 2
    [AbstractRepository] => 2
    [UserInterface] => 2
    [AbstractController] => 2
    [Index] => 2
    [Constraint] => 2
    [DoctrineDataCollector] => 2
    [ValidateSchemaCommand] => 2
    [DoctrineCommand] => 2
    [Writer] => 2
    [DoctrineExtension] => 2
    [MetadataFactory] => 2
    [Reader] => 2
    [Enum] => 2
    [Registry] => 2
    [DefaultNamingStrategy] => 2
    [FilterInterface] => 2
    [AsseticNode] => 2
    [FilesystemCache] => 2
    [ConfigCache] => 2
    [ArrayCache] => 2
    [AsseticTokenParser] => 2
    [AssetFactory] => 2
    [FilterCollection] => 2
    [DirectoryResourceIterator] => 2
    [CoalescingDirectoryResource] => 2
    [FileCache] => 2
    [RedisCache] => 2
    [StaticPHPDriver] => 2
    [PHPDriver] => 2
    [ManagerRegistry] => 2
    [PreUpdateEventArgs] => 2
    [PersistentObject] => 2
    [ConnectionException] => 2
    [QueryException] => 2
    [QueryBuilder] => 2
    [TableGenerator] => 2
    [OnClearEventArgs] => 2
    [LoadClassMetadataEventArgs] => 2
    [Comparison] => 2
    [ArrayCollection] => 2
    [ClassLoader] => 2
    [CompositeExpression] => 2
    [ExpressionBuilder] => 2
    [LifecycleEventArgs] => 2
    [AbstractLexer] => 2
    [AbstractExecutor] => 2
    [Answer] => 2
    [MultiTableDeleteExecutor] => 2
    [AbstractTreeRepository] => 2
    [Filesystem] => 2
    [TranslationRepository] => 2
    [AbstractTranslation] => 2
    [AbstractPersonalTranslation] => 2
    [Local] => 2
    [MaterializedPathRepository] => 2
    [Closure] => 2
    [ContactMessageRepository] => 2
    [MaterializedPath] => 2
    [SecurityListener] => 2
    [Size] => 2
    [SoftDeleteableFilter] => 2
    [LogEntry] => 2
    [IpTraceable] => 2
    [AbstractLogEntry] => 2
    [LogEntryRepository] => 2
    [Loggable] => 2
    [Language] => 2
    [ReferenceIntegrity] => 2
    [Blameable] => 2
    [Uploadable] => 2
    [Translatable] => 2
    [SoftDeleteable] => 2
    [Nested] => 2
    [FilesystemMap] => 2
    [BadResponseException] => 2
    [FileCookieJar] => 2
    [RequestMediator] => 2
    [CookieJar] => 2
    [AnswerType] => 2
    [BooleanToStringTransformer] => 2
    [ClientException] => 2
    [ContactMessageType] => 2
    [MimeTypeGuesser] => 2
    [CouldNotRewindStreamException] => 2
    [ContactMessage] => 2
    [PhotoType] => 2
    [CookieJarInterface] => 2
    [SubmitType] => 2
    [Statement] => 3
    [Proxy] => 3
    [MappingException] => 3
    [FileLoader] => 3
    [FilesystemLoader] => 3
    [Server] => 3
    [ClassMetadataFactory] => 3
    [Column] => 3
    [Imagine] => 3
    [Table] => 3
    [CacheInterface] => 3
    [ParseException] => 3
    [Shell] => 3
    [Font] => 3
    [RedirectableUrlMatcher] => 3
    [Drawer] => 3
    [ValidatorInterface] => 3
    [Effects] => 3
    [AsseticExtension] => 3
    [DumperInterface] => 3
    [TypeTestCase] => 3
    [HttpException] => 3
    [Header] => 3
    [Layers] => 3
    [Cache] => 3
    [Event] => 3
    [ConnectionFactory] => 3
    [Url] => 3
    [MimeTypeGuesserInterface] => 3
    [Required] => 3
    [ClassUtils] => 3
    [FilterManager] => 3
    [Inflector] => 3
    [ProfilerController] => 3
    [Lexer] => 3
    [ApcCache] => 3
    [PhpFileLoader] => 3
    [XmlFileLoader] => 3
    [AccessDeniedException] => 3
    [ResourceInterface] => 3
    [Form] => 3
    [FileResource] => 3
    [DirectoryResource] => 3
    [Comparator] => 3
    [Extension] => 3
    [RoutingExtension] => 3
    [Timestampable] => 3
    [ImageInterface] => 3
    [Stream] => 3
    [LoginController] => 3
    [ControllerResolver] => 3
    [Helper] => 3
    [Route] => 3
    [LoggerInterface] => 3
    [Account] => 3
    [MetadataFactoryInterface] => 3
    [Compiler] => 3
    [Question] => 3
    [PropertyMetadata] => 3
    [ErrorHandler] => 3
    [SurveyController] => 3
    [CompanyReviewController] => 3
    [Profile] => 3
    [Entity] => 3
    [AbstractNode] => 3
    [Spellcheck] => 3
    [Grouping] => 3
    [Parameter] => 4
    [UnexpectedTypeException] => 4
    [Application] => 4
    [FunctionNode] => 4
    [AppKernel] => 4
    [SearchType] => 4
    [Range] => 4
    [SecurityExtension] => 4
    [Node] => 4
    [Locale] => 4
    [TestBundle] => 4
    [Highlighting] => 4
    [MoreLikeThis] => 4
    [Cookie] => 4
    [AbstractCommand] => 4
    [ExpressionLanguage] => 4
    [ClientInterface] => 4
    [Token] => 4
    [File] => 4
    [YamlFileLoader] => 4
    [Schema] => 4
    [WebTestCase] => 4
    [Translator] => 4
    [FileLocator] => 4
    [Reference] => 4
    [Container] => 4
    [FacetSet] => 4
    [Autoloader] => 4
    [AdapterInterface] => 4
    [Request] => 5
    [AnnotationDriver] => 5
    [Stats] => 5
    [Connection] => 5
    [Type] => 5
    [AbstractResource] => 5
    [Debug] => 5
    [LogicException] => 5
    [Loader] => 5
    [Collection] => 5
    [Expression] => 5
    [Translation] => 5
    [Command] => 6
    [Response] => 6
    [LoaderInterface] => 6
    [Logger] => 6
    [UnexpectedValueException] => 6
    [User] => 6
    [ResponseParser] => 6
    [TestCase] => 6
    [BadMethodCallException] => 6
    [Parser] => 7
    [Validator] => 7
    [Image] => 7
    [ClassMetadata] => 7
    [Events] => 8
    [OutOfBoundsException] => 8
    [DefaultController] => 8
    [Field] => 8
    [Document] => 9
    [RequestBuilder] => 10
    [ODM] => 10
    [ORM] => 11
    [Client] => 11
    [Driver] => 12
    [Yaml] => 12
    [Xml] => 13
    [Version] => 13
    [Query] => 14
    [Service] => 14
    [Annotation] => 15
    [Result] => 15
    [Exception] => 15
    [ExceptionInterface] => 17
    [InvalidArgumentException] => 18
    [RuntimeException] => 19
    [Configuration] => 40
)

475

Warto jeszcze zauważyć, że projekt wykorzystuje również biblioteki, które nie korzystają z przestrzeni nazw (klasy typu Twig_TokenParser_Extends czy Squiz_Sniffs_CSS_ColonSpacingSniff) co jeszcze zaniża wynik.

[nrm]

czemu "nawet"? To namespace dla kontrolerów jest jakaś abstrakcją?

Bo jest spór o to podobny jak w tym wątku (IMG:style_emoticons/default/wink.gif)