Temat znany niektórym od przynajmniej miesiąca - a nie widze żeby był tu na forum poruszany.

w skrócie:
Developerzy PHP postanowili zmienić domyślny namespace separator. Po owocnej dyskusji podjęli dość kontrowersyjną decyzje aby nowym namespace separator został backslash - \. Uzasadnienie decyzji znajduje się tutaj - http://wiki.php.net/rfc/namespaceseparator. News informujący tutaj - http://news.php.net/php.internals/41374.

Na wielu blogach zaczęły się pojawiać komentarze np.:
http://loveandtheft.org/2008/10/26/set-sai...php-namespaces/
http://phpimpact.wordpress.com/2008/10/28/...es-controversy/

Jakie są wasze opinie na temat tej decyzji?

Dla mnie jest to poroniony pomysł i wprowadza niepotrzebne zamieszanie. Po raz kolejny próbuje się wymyślać koło na nowo i tworzyć rozwiązania "pod siebie" zamiast pod developerów.

Hmmm, nie wiem czy to temat na Hydepark, ale co tam. Z mojego zrozumienia całej dyskusji to wybór backslasha daje sens. Oczywiście estetycznie rzecz biorąc to Paamayim Nekudotayim (:: ) byłby znacznie lepszy, ale weźmy pod uwagę poniższy przykład:

[PHP] pobierz, plaintext 
<?php
Some::Fun::stuff()
?>
[PHP] pobierz, plaintext 

I niech mi ktoś powie czy stuff() jest funkcją statyczną klasy Fun, czyteż zwyczajną funkcją w przestrzeni Fun. Użycie backslasha eliminuje ten problem. A backslash jest i tak lepszy (IMO) od innych proponowanych rozwiązań jak ::: cz :.:

A co tu poruszać? Możemy sobie gadać a i tak wiadomo, że developerzy PHP to ludzie, których większośc decyzji jest zła. Więc co to zmieni?

Ja uważam, że :: było najlepszym rozwiązaniem.

Pomimo tego przykład na blogu w pierwszym linku pokazuje raczej złe nawyki niż problem (koleś źle się zabrał za opisanie problemu). Stringi w takich przypadkach powinno się umieszczać w apostrofach.

Zawsze mozna liczyc ze jak sie odpowidnio duzy szum dookola sprawy zrobi to ktos sie poknie w glowe i zobaczy bezsenownosc tego rozwaizania


Jak pokazuje drugi podlikowany blog, w javie, C, pythonie nie ma tego typu problemow

Dyskusja o namespace'ach toczy się bodajże od pięciu lat. Ja tam się cieszę że będą, a takie detale jak ten separator to fistaszki. Znacznie bardziej interesująca jest IMO tematyka namespace resolution, która jest jeszcze nie rozstrzygnięta. A co do szumu, occulkot, to bym na to nie liczył. Ludzie na @internals próbowali, ale większość devów jest definitywnie zmęczona tą tematyką, i czują że podjęli wybór.

Jasne, i wszystko fajnie, ale Java, C i Python to diametralnie inne języki z innym designem. Ich rozwiązanie nie sprawdziłyby się w PHP (niestety).

Ale z drugiej strony pogłądbianie smietnika jakim jest PHP to też zle wyjście.
To, że PHP taki a nie inny "design" i taką specyfikę to często efekt tego, że nikt nie patrzył w przyszłość. Pewnie chłopaki kierują się mottem "Zróbmy graciarnie, będzie fajnie". Na wprowadzanie jednolitych rozwiązań nie jest nigdy za późno.

mike, zgadzam się z tobą, i w idealnym świecie, ktoś wziąłby się do kupy i napisał OOP w PHP od nowa, jednolicie i czysto. Jednak developerzy PHP są zawieszeni w jakimś ekstremistycznym podejściu do utrzymania BC. Dopóki od tego nie odejdą raczej nic się nie zmieni. Nie bronię ich podejścia, jeno konstatuję.

Parodia łoo matko backslash ahahahah
Niech ktoś tym panom zabawki zabierze.

Sa inne jezyki z lepszym OOP, skoro PHP ma miec nowe OOP (i zakladam ze obiektowe bilbioteki) i trzeba sie uczyc wszystkiego od nowa i nikt tego nie bedzie mial na serwerach to po co czekac, jak mozna juz teraz przesiasc sie na Ruby, Python.

Hmm... Wydaje mi się, że to dobre posunięcie.

Sam przykład:


Co miałby wykonywać? Statyczną metodę w obiekcie Bar na przestrzeni Foo, czy funkcję doe z przestrzeni Foo? A co, jak mielibyśmy i funkcję doe na przestrzeni, i statyczną metodę doe na obiekcie Bar? Zastosowanie Foo\Bar::doe(); jeszcze da się znieść.

Co do argumentu "Foo\tBar", to powiem, że przyjętym standardem jest rozpoczynanie nazwy klasy z dużej litery. A kolejny argument, że niby ogranicza to wolność wyboru nazwy, to może zezwolić na nazwy zaczynające się od $, :, :: oraz &... ? W końcu powinna być wolność.

Nie jestem pewien, bo jeszcze się nie bawiłem na tyle, by sprawdzić jaki jest poziom zagnieżdżeń, ale logiczne się wydaje, że Foo::Bar::oops() to metoda oops() klasy Bar w przestrzeni Foo i taka interpretacja wydaje mi się naturalna.

Pozdrawiam

Jednoznaczne ale, hmm, runtime-dependent czyli nie wiesz co uruchomi dopoki skrypt nie zostanie uruchomiony (bo np nie zaladowales 1 pliku itp)
http://pl.php.net/manual/en/language.namespaces.rules.php

Odnośnie zagnieżdżeń. W zapisie:

Foo::Bar::Joe

elementy "Foo" i "Bar" muszą być przestrzeniami nazw, jeśli nie dopuszczamy zagnieżdżania klas.

Foo::Bar::Joe()

Ten zapis jest wieloznaczny - może oznaczać funkcję w przestrzeni "Foo::Bar", albo metodę statyczną klasy "Bar" w przestrzeni nazw "Foo".

Moim zdaniem rozwiązania problemu należałoby poszukać w innym miejscu, mianowicie przyjrzeć się obsłudze klas statycznych, w która w PHP może być w 100% jednoznacznie zrobiona jednym operatorem (według poniższych wzorów dokonuję parsowania obsługi OOP w OPT):



Wtedy :: mógłby być swobodnie stosowany do przestrzeni nazw. Natomiast sam wybór backslasha to dla mnie już dyskusja w stylu "co jest lepsze: kolor zielony czy czerwony". Z przepisywaniem PHP życzę ogólnie powodzenia. Może i sam bym się za to kiedyś wziął, ale na razie to podejście polskich programistów do open-source skutecznie mnie do tego zniechęca.

Ja dlugo o tym myslalem - wydaje mi sie byc poronionym pomyslem. BC - niech sobie robie co chca. Ja sie zgadzam z @dr_bonzo nt jezykow z lepszym OOP - i osobiscie zaczynam sie sklaniac w ta strone. Zreszta moja randka z PHPem powoli sie konczy Propagandy nie mam zamiaru szerzyc tak wiec dziekuje za uwage

Heh, jak znam życie, to trzeba poczekać do edycji stabilnej, dopiero wtedy wyjdzie, kiedy zdecydują się na coś konkretnego.

@Zyx - rzeczywiście pomysł z -> jest przedni - podsunąłeś go devom php?
@NuLL - marudzisz, a podobno to ja jestem marudny

Pozdrawiam

W sobotę miałem okazję uczestniczyć w konferencji, na której poruszany był temat PHP 5.3 oraz oczywiście namespace. Generalnie widać było, że zespół jest mocno zmęczony wałkowaniem tego tematu. Steph Fox przyznała, że mieli wybór między opcjami złymi a gorszymi. Rozpatrywano paamayim nekudotayim jako separator ale ze względów na konstrukcję enginu ta opcja odpadła. Na propozycję poprawy enginu Scott MacVicar odparł, że patche są mile widziane . Co do namespaców to jeszcze niczego nie wiadomo na pewno - ta część ma być jeszcze poddana gruntownym modyfikacjom.
A tak swoją drogą to nie miałem pojęcia, że core team PHP ma wielkie kłopoty z wolontariuszami. Widać, że bardzo im zależy na osobach chcących się zaangażować w rozwój języka - potrzebują właściwie ludzi do wszystkiego - od pisania modułów, poprzez testy aż po tworzenie dokumentacji. Tak więc do dzieła...

W C# jak mamy klasę Bar w przestrzeni nazw Foo oraz przestrzeń nazw Foo.Bar dostajemy błąd:


Dlaczego by nie zrobić takich ograniczeń w PHP?

[PHP] pobierz, plaintext 
<?php
 
namespace Foo;
 
class Bar
{
 
}
 
function baz()
{
 
}
 
namespace Foo::Bar; // Fatal error
 
namespace Foo::baz; // Fatal error
?>
[PHP] pobierz, plaintext 

Tak się zastanawiam, co by to było, gdyby społeczność programistów zbojkotowała 6. wersję procesora po wypuszczeniu...

Może wreszcie developerzy poszliby po rozum do głów... :/

A nie lepiej zorganizować akcję, zebrać ileśtam tysięcy podpisów i pokazać, ile osób pragnie bardziej odważnych zmian? Póki "szóstka" ma status "dev", wszystko jest możliwe; gdy wejdzie w stan bety, już nie bardzo.

Cysiaczek -> wyobraź sobie, że tak.

Jestem za, i tak już jest bu... bałagan.

Dla zainteresowanych, polecam http://docs.php.net/manual/en/language.namespaces.php - wciąrz aktualizowany rozdział, ale daje dobry obraz funkcjonalności.

A ty wciąż nie zaktualizowałeś swojego umysłowego słownika ortograficznego.


Co do separatora namespace to rzeczywiscie uwazam ze \ nie jest do tego odpowiedni.
Co do innych separatorów to nie mam pomysłów. Ale pomysł Zyxa jest zdecydowanie nieprzemyślany. Teraz wyraźnie widać różnice pomiedzy
Klasa::metoda()
a
$klasa->metoda();

// Kolejne posty i kolejne chamskie docinki, jeśli masz jakieś kompleksy to idź do lekarza.
// Jeszcze raz zobaczę wypowiedzi w tym stylu to dostaniesz moderacje postów na miesiąc.
// ~webdice

Ja widze drobna roznice miedzy:
Klasa->metoda() a $klasa->metoda();

Tak. Ale nie jest ona tak czytelna jak aktualna. Aktualna znacznie poprawia czytelnosc i szybko mozna zrozumiec ja dla osoby ktora ma zapoznac sie z tym kodem.

Ja się zastanawiam jak to będzie z podpowiadaniem składnie w IDE wspierających PHP. To chyba nie będzie najłatwiejsza rzecz do zaimplementowania... ma nadzieję, że się mylę.

Polecam lekturę http://greg.chiaraquartet.net/archives/198...Oh-my!.html (punkt PEAR and namespaces. Oh MY!).

Osobiście nie widzę takiego problemu, jak większość ludzi. To tylko jedna kolejna rzecz do nauczenia, a sytuacja tak naprawdę wygląda tak, że cokolwiek by nie zrobili czy wybrali, to byłyby lamenty i narzekania. I zanim pojawią się kolejne genialne propozycjne na namespaces, to polecam ogromną lekturę na php internals.