Splatch’s devblog

Od jakiegoś czasu trwają prace nad drugą wersją propela. Do najważniejszych zmian należy przejście na PDO. Jest to fakt, który najbardziej mnie smuci. Koszt zwiazany z wykorzystaniem Creole był zbyt wysoki jak na ORM i autorzy przeszli na znacznie szybsze PDO. W tej chwili dla każdej bazy danych jest stworzony odpowiedni, prosty adapter. Ilość obsługiwanych baz danych nie wzrośnie. W dalszym ciągu będzie to MySQL, PostgreSQL, Oracle, Microsoft SQL Server (Sybase), SQLite.
Niewątpliwą nowością jest cache, który będzie prawdopodobnie funkcjonował jako kolejny adapter. Mam nadzieję, że dodanie cache przyśpieszy nieco Propela, ponieważ część obiektów, mimo, że nie jest zmieniana (jest to fragment złączenia) zawsze jest pobierana i transformowana.
Spore zmiany zajdą w Criterii. W drugiej wersji budowanie złożonych warunków stanie się banalne, a to za sprawą całkiem nowej implementacji. Doczekamy się w końcu obsługi idenity map, dzięki czemu klucz główny zawsze będzie wskazywał ten sam obiekt.

Więcej informacji dla zainteresowanych nową wersją do znalezienia na wiki propela, na które serdecznie zapraszam. :)

W czasach kiedy najbardziej trendy jest YAML twierdzę, że jest on niczym w porównaniu do tego, co oferuje XML. DLaczego?

Dlatego, że tworząc dowolny dokument XML mogę go w bardzo prosty sposób rozszeżyć. Jak? Poprzez XInclude. Jego obsługa jest nawet w PHP więc nie ma z tym jakichkolwiek problemów. Definiuję tylko odnośnik i mam dołączony ten XML [po wykonaniu $DOMDocument->xinclude();].

Kolejna sprawa. Walidacja. Nie muszę tworzyć żadnego kodu w PHP by sprawdzić poprawność XMLa. Wystarczy, że stworzę dobry schemat w XSD i mam walidację załatwioną bez jakiegokolwiek warunku. Do tego dochodzą ograniczenia takie jak rekurencja. W PHP  muszę to załatwiać poprzez wielokrotne wywołanie funkcji, które za każdym razem wydłuża czas. Normalnie załatwi mi to DOM XML, który jest napisany w C i będzie znacznie szybszy.

Parę linijek kodu i moja konfiguracja zapisana w XMLu stanie się czytelna dla oka przy użyciu XSLT w połączeniu z PHP.
Także czy dalej YAML i INI jest najlepszym sposobem przechowywania konfiguracji? Moim zdaniem nie – i nigdy nie będzie. XML jest technologią, która fakt faktem, jest nadmiarowa, ale oferuje bardzo dużą popularność. Można mówić, że YAML jest czytelny i przyjazny, ale nie oferuje takiej funkcjonalności przy takim małym nakładzie sił. XML jest wszędzie, jest prosty. Sprawdzanie poprawności dokumentu można załatwić poprzez inny XML a jego prezentacje poprzez kolejny, także znajomość technologii związanych z XMLem jest niewątpliwie przydatna.

Jakiś czas temu w pracy dostałem troszkę inne zadanie. Mianowicie, poprawić konfigurację Apache. Konfiguracja jak konfiguracja, to nie był problem – schody zaczęły się z dodaniem virtual hostów. Zawsze miałem z tym problem, teraz do tego dochodziło skonfigurowanie tego wszystkiego z użyciem SSLa. Jak już sobie z tym poradziłem – doszło kolejne zadanie, czyli konfiguracja proxy! Problem polegał na tym, że nasza kontrolka webowa komunikuje się z serwerem, z tym, że serwer może stać na dowolnej maszynie.
Przyznam, że po tym co przeszedłem z tym SSLem i vhostami miałem serdecznie dość wszystkiego co było z httpd.conf związane. ;)

W ramach pomocy otrzymałem od project managera link z opisem konfiguracji jakiegoś proxy. No to do dzieła, gotowiec – na dole.

ProxyRequests on
# ProxyPass "lokalny folder" "serwer zewnetrzny"
ProxyPass /delta/ https://delta.dywicki.pl/
# każde żądanie do tego folderu
ProxyPassReverse /

W ten sposób, wszystkie żądania, które trafiają do /delta/ idą na delta.dywicki.pl. Rzecz mała i prosta. Jedyny minus tego rozwiązania to konieczność konfiguracji proxy i włączenie modułów które domyślnie są wyłączone.

Od publikacji ostatniej noty parę osób proponowało mi podjęcie prac nad Mojavi 4. Chcę wyjaśnić, dlaczego Mojavi 4 nie będę się zajmował.

1. Nie ma nikogo kto byłby w stanie pomóc mi przy projekcie. Obaj byli developerzy zakończyli swoją przygodę z PHP. Nie ma również żadnej społeczności, która jest w stanie zająć się forum, wyłapywaniem błędów – jednym słowem – to by było to samo co robiłem wcześniej przy własnym frameworku.

2. Są projekty, które być może w tej chwili nie dorównują Mojavi 4, lecz są na tyle dobre, że w przyszłości mogą osiągnąć próg czwórki a nawet go przekroczyć.

3. Podobna sytuacja miała miejsce kiedy Sean Kerr zrezygnował z rozwijania Mojavi 3. Później prace nad czwórką przejął Tyler. Gdybym teraz miał zacząć poprawiać Mojavi 4 wyszłaby piątka, której prawdopodobnie bym nie skończył. Czy ktoś by się zajął pozostawioną wcześniejszą wersją?

4. Nie chcę tworzyć większego projektu w PHP, mocno prawdopodobne, że po miesiącu, dwóch po prostu bym zrezygnował z pisania Mojavi pogarszając i tak już wystarczająco ciężką sytuację.
Projekt, na który zwrócę teraz baczniejszą uwagę to Agavi. Jest w nim sporo znajomych rzeczy z trójki. Wersja 0.11 jest dużym krokiem w stosunku do 0.10, w której były same poprawki. W trunku widać, że developerzy nie poprzestali na poprawkach i postanowili dodać funkcjonalności. Do ciekawszych należą: routes (Symfony wymięka), translates, output types (w połączeniu z routes daje świetne możliwości), view renderers.

Dzisiejszego dnia chciałem napisać coś o Creole by pokazać, że ten sterownik oferuje ciekawą funkcjonalność, ale nie będzie o tym.

To co zmieniło moje zamiary to rozmowa z Tylerem Tomphinsem, osobą prowadzącą od dłuższego czasu projekt Mojavi.

Kontakt z Tylerem jest ciężki, ponieważ on mieszka po drugiej stronie globu. Nasze rozmowy do tej pory wyglądały inaczej, niestety ta, którą zakończyłem przed chwilą zmienia wszystko.

Dowiedziałem się, że Mojavi 4 zostaje zawieszone. Framework, w którym pokładałem ogromne nadzieje, który miał szanse zmienić nieco oblicze aplikacji pisanych w PHP umiera. Można powiedzieć, że historia się powtórzyła, jest to samo co z trójką (mike_mech wykrakał), która została zawieszona dawno, dawno temu. Ówczesny lider projektu – Sean Kerr zrezygnował z jego prowadzenia na rzecz Tylera..

Od tego czasu wiele się zmieniło. Co najważniejsze, zaczęła powstawać dokumentacja, wszystko szło w dobrą stronę, repozytorium może nie tętniło życiem, ale wszystko szło powoli w dobrym kierunku.

To wszystko się skończyło na utracie danych z serwera Mojavi, który miał miejsce bodajże na początku lipca.
Najlepszy framework PHP który powstał do tej pory. Żal, że to go spotyka. Ciekawe są okoliczności rezygnacji Tylera z prowadzenia Mojavi, w ogóle z PHP. Jakiś czas temu postanowił przyjrzeć się Ruby i Ruby on Rails by wzbogacić projekt. Teraz do Mojavi a tym bardziej do samego PHP Tyler nie ma zamiaru wracać, ponieważ jest oczarowany wyżej wymienionym językiem. W sumie nie dziwię się mu i szanuję jego decyzję.

Szkoda, wielka szkoda projektu, danych, społeczności.

Zgodnie z tym, co napisałem na forum php.pl zapraszam do ocen, bądź w temacie bądź tu, w zależności od sympatii. ;)

Na początku odpowiedź na post, który napisał Zyx.

Aktualnie każdy, kto chce napisać nowe rozszerzenie do PHP, musi tylko znać język C, znać cel swej pracy oraz przeczytać rozdział 46 dokumentacji PHP zatytułowany “Zend API: Hacking the Core of PHP” i poświęcony właśnie tworzeniu modułów.

Zend API to nie wszystko. Moduły kompilowane nie są wyjściem super-uniwersalnym. Na co drugim serwerze nie ma opcji by dorzucić własne rozszerzenie. Wiele modułów z PECLa leży tam od lat, są one praktycznie nie rozwijane, także ich ilość niewiele może poświadczyć.

Projekt ten nie miał nigdy poprawiać po egoistycznie nastawionych twórcach baz danych oraz ich kreatywnym podejściu do implementacji standardu ANSI SQL, ale na plus należy zaznaczyć, że niektóre braki bibliotek klienckich są emulowane (np. podpinanie).

Nikt nie mówi, że PDO miałoby to poprawiać. Spójrz na JDBC, producenci baz samodzielnie dostarczają sterowników do połączeń i dbają o to by były zgodne z własną bazą oraz kolejnymi standardami w JDBC.

Ale głupotą byłoby negowanie go tylko dlatego, że w kwestiach wielkoskalowych ma braki, a Zend ostatnio stosuje dziwne podejście w kwestii doboru priorytetów i debugowania swego sztandarowego projektu.

Diabeł tkwi w szczegółach. Brak stosownych narzędzi i rozwiniętych rozwiązań technologicznych jest sporym problemem, który znacznie utrudnia tworzenie aplikacji.

XML i SAX
SAX jest świetnym standardem. Niestety, ustawianie gromady opcji dla parsera to jakaś porażka. Do tego domyślne zmienianie nazw tagów na wielkie litery.. jak by ktoś z tego korzystał.
SAX mógłby być świetnym rozwiązaniem, gdyby istniała klasa domyślnego parsera, która wymuszałaby implementacje tylko 2 metod – startElement i endElement. Niestety, jesteśmy skazani na to co, jest w PEAR, czyli kod pisany pod PHP 4.
Poza tym problem z SAXem w PHP jest taki, że jeśli ktoś chce korzystać z przestrzeni nazw w dokumencie, którego używa ma niewielkie szanse na to, że cokolwiek uda mu się ugrać, ponieważ parser nie przekazuje do handlera informacji o tym do jakiej przestrzeni nazw należy tag. Dla przykładu w Javie metoda startElement wygląda w następujący sposób:

void startElement(string uri, string localname, string qname, attributes atts)
a w PHP
void startElementImpl(resource parser, string localname, array atts)
czyli zupełnie tak samo jak by tych przestrzeni nie było. Jedyny sposób to wyciąganie prefiksu w nazwie (bo otrzymujemy np foo:bar) i sprawdzanie względem wcześniej zdefiniowanych poprzez xmlns.

DOM
Za implementację DOM Panom z Zenda należą się gratulacje, przede wszystkim dlatego, że w końcu jest to moduł doprowadzony do standardu, zgodnie z zaleceniami W3C. Nie będę już narzekał, że jest to DOM Level 2 a nie 3 co by nie było, że się za wiele czepiam ;). Świetnie, że DOM jest częścią Core PHP. Nie ma problemów z tym, czy DOM jest czy nie.

Testując DOM przed napisaniem tej noty trafiłem na błąd w obsłudze encji. Działają one w atrybutach ale nie w treści. Sprawa wygląda w ten sposób, że encje predefiniowane takie jak "e; są widoczne, zatem gdzie są moje? Uciekły bo się przestraszyły tagów.

SimpleXML
SimpleXML jest bramką pomiędzy DOM a SAX. Oferuje mniejszą funkcjonalność niż DOM, ale wymaga o wiele mniej pracy niż SAX. Po prostu, wczytujesz plik i działa. Niestety, nie jest tak różowo. W nim również znalazłem niedoróbkę. Nie jestem pewien czy nie została ona załatana, problem polegał na gubieniu atrybutu przy kolekcji. Denerwuje mnie również to, że nikną mi informacje o przestrzeni nazw. Jeśli przeglądam dokument iteracyjnie tracę informację o tym z jakiej przestrzeni jest element.

XSLT
Zbyt małe możliwości połączenia PHP i samego procesu transformacji. Do XSLT można przekazać tylko ciągi, zatem nie ma mowy o tym by wrzucić tablicę i na jej podstawie wykonać jakąś iterację. Niestety, nie te czasy. Plusem jest to, że można tworzyć funkcje do których parser potrafi się odwołać.. niestety są to albo funkcje albo statyczne odwołania do klas.

XSL-FO
XSL-FO to standard, który umożliwia przekształcenie dowolnego dokumentu XML do postaci binarnej takiej jak PDF. Niestety w PHP nie doczekaliśmy się jeszcze żadnej implementacji tego standardu, poza jedną klasą w PEAR, która usiłuje wykonać transformację przy użyciu Javy.

XSD
Z XSD w PHP jest zasadniczy problem. Nie istnieje. Można sprawdzić czy dokument jest zgodny ze schematem korzystając chociażby z DOMa, niestety nie ma żadnych narzędzi, które umożliwiają tworzenie klas ze schematu. Skala problemu znacznie się powiększa w chwili gdy korzystamy z WSDL, które pośrednio korzysta z XSD. Nie ma opcji, żeby stworzyć jakikolwiek typ złożony w PHP bez własnego kodu.

Rozbudowa o przykłady, być może wkrótce.

Postami w tej kategorii chcę pokazać jak dalekie PHP jest od ideału. Mam nadzieję, że większość z tego co piszę kiedyś zostanie poprawiona, nie mniej póki co, są to grzechy ciężkie, które pokazują słabości PHP.

Zend

Zend jest firmą, która bez wątpienia ma największy wpływ na PHP. To Zend tworzy najważniejszy element PHP jakim jest Zend Engine.

To co mam do zarzucenia Zendowi to nieumiejętność wykorzystania swojej pozycji. Nie potrafi on wykorzystać swojej pozycji by ugrać coś na rzecz PHP. Być może dlatego, że jako firma jest zbyt mały by cokolwiek znaczyć. Od jakiegoś czasu Zend powoli produkuje papkę marketingową, którą wciska, że PHP jest enterprise podczas gdy samemu PHP jest do tego bardzo daleko. To, że został zmieniony silnik obsługujący obiekty, upodobniono składnię do Javy, wydano nową (piątą) wersję PHP nie czyni go enterprise.

Kiedy PHP stanie się językiem Enterprise? Kiedy dostarczy stosownych narzędzi i technologii. Niestety w chwili obecnej nie ma ani jednego ani drugiego. PHP jest wciąż językiem, który ma do tego aspiracje, ale nie ma możliwości (zupełnie tak jak Zend). Mam nadzieję, że z biegiem czasu i not z tej kategorii będę to udowadniał.

Z czym się do tej pory kojarzy PHP? Ze “stronkami” produkowanymi przez gimnazjalistów i licealistów. Nie odbiega to od faktów. Pytanie, dlaczego Zend zmierza w kierunku większych klientów? Odpowiedź jest oczywista, większe pieniądze. Tylko, za przeproszeniem, z czym do ludu?!

API, Technologie

Brak jakiegokolwiek API dla rozszerzeń. Parsery XML to nie tylko SAX, nie tylko DOM. Jeśli ktoś chce zaimplementować cały standard samodzielnie czy też go rozszerzać (choćby w samym PHP!) powinna być taka możliwość, niestety do tej pory jej nie ma i prawdopodobnie nie będzie, ponieważ PHP nie jest porządnie zaprojektowane.
Inną sprawą jest to, że nikt się tym nie zajmował i nie zajmuje. Błędne koło się zamyka, nikt nie myśli nad nowymi, porządnymi rozwiązaniami oraz technologiami opartymi o ten język, ponieważ PHP nie jest gotowe na taki krok. Wystarczy spojrzeć na Javę… Dla przykładu podam platformę J2EE. Sun publikuje pełną specyfikację i dostarcza przy okazji własny serwer, który w pełni tą specyfikację obsługuje. Nie przeszkadza to by równocześnie na rynku były obecne inne podmioty takie jak JBoss, BEA Web Logic i podstawa wszystkiego – Apache Foundation z Tomcat`em.

Społeczność i Zend Framework

Jak wiadomo społeczność PHP nie jest mała. Względem innych języków można powiedzieć, że jest ogromna. Nie mniej problemem społeczności jest jej podział i brak konsolidacji. Zend nie sprzyja tworzeniu społeczności wokół PHP. Przykładem może być Sun (który stoi na podobnej pozycji z Javą). Czym najłatwiej zgromadzić społeczność wokół własnej platformy? Oczywiście – projektami. Im więcej projektów tym więcej zaangażowanych ludzi i osób oraz firm nimi zainteresowanych. Tymczasem, co robi Zend? Prze ślepo w jednym kierunku, mianowicie w stronę własnego Frameworka, który od ideału jest daleki.

Jeden framework nie zdobędzie serc wszystkich programistów tym bardziej, że w PHP korzystanie z gotowych rozwiązań do w dalszym ciągu rzadkość. Zamiast wspierać chociażby konkurencyjne rozwiązania Zend nie robi nic, nawet nie kiwa palcem by przyciągnąć do siebie projekty. Przykładem może być Cake PHP, wokół którego zgromadziła się pokaźna grupka osób oraz Prado, które jest rozwiązaniem zgoła innym, działającym na zupełnie innych zasadach. Czyżby Zend nie wiedział, że w mnogości tkwi siła? Najwyraźniej tak, nie wspierając społeczności PHP wiele traci. To działa w obie strony, tak samo jak Zend może liczyć na takie samo wsparcie społeczności jako ono na jego.
PDO

PDO jest rozwiązaniem zdecydowanie spóźnionym i niedostatecznym jeśli myślimy o poważnych zastosowaniach. Podczas, gdy na rynku rozwijały się rozwiązania takie jak AdoDB i jego klony Zend nic nie robił w celu zatrzymania tego procesu. Doszło do sytuacji, kiedy PHP obsługuje wiele baz ale przez skrajnie różne rozszerzenia i funkcje. Jeszcze do niedawna było poprawiane rozszerzenie do obsługi PostgreSQL, by przypominało chociaż pozostałe. Do niedawna korzystanie chociażby z dwóch różnych baz danych wymuszało korzystanie z paskudnie napisanego AdoDB bądź implementowania tego samodzielnie.

PDO miało to zmienić, ale niestety nie do końca. PHP5 nie jest jeszcze zainstalowane na wielu serwerach, nie wspominając PHP 5.1 od którego PDO zostało wprowadzone. Wcześniejsze rozwiązania bazujące na “tradycyjnych” implementacjach używających funkcji natywnych nie mogą przeskoczyć nagle na PDO a nie mówiąc już o brakach w PDO.
Nie obsługuje ono wszystkich baz jakie do tej pory obsługiwało PHP oraz nie uwalnia definitywnie od różnic pomiędzy bazami. Pod tym względem PDO może przebić chociażby Creole nie mówiąc już o AdoDB, które obsługuje praktycznie wszystkie bazy, jakie do tej pory w PHP się pojawiły.

PHP6

Zbyt małe zmiany. Tak jak pisałem wcześniej, to jest powolna ewolucja, podczas gdy PHP jest potrzebna przemiana. Jeśli PHP ma z brzydkiego kaczątka kiedykolwiek stać się łabędziem to w tym tempie jeszcze lata ciężkiej i rzemieślniczej pracy przed nami, tym bardziej, że jesteśmy jeszcze w jajku, z którego się nie wykluliśmy.

Czy dodanie przestrzeni nazw diametralnie zmieni PHP? Zmieni zapewne ale nie na tyle by instytucje takie jak banki zainwestowały w PHP, bo jak wcześniej pisałem, nie jest to powód sam z siebie. Muszą się pojawić narzędzia, które wspomagają, uproszczają, porządkują prace nad bardzo dużymi aplikacjami. Ciągłe luki, niedoróbki, wydania, które są jednodniowe z racji krytycznych błędów bezpieczeństwa. To wszystko nie sprzyja budowaniu pozytywnego wizerunku samego PHP.

Zaprawdę, zaprawdę powiadam Wam drodzy czytelnicy Zend Framework do pełnej implementacji MVC ma jeszcze bardzo duży kwał drogi.

Dzisiejszego dnia postanowiłem poświęcić parę minut na bliższe spotkanie z ZF. Jak się szybko okazało nie był to czas spędzony bezowocnie. Utrwaliłem się w przekonaniu, że ZF to nie jest to czego szukam oraz znalazłem buga i to dość niewygodnego.. ;)

Dlaczego moje uprzedzenie do ZF nie zmalało a tylko wzrosło? Dlatego, że to co w sumie zobaczyłem odbiega od znanego mi (z innych frameworków) MVC. Może potraktuję Was tutaj odrobiną kodu:

< ?php

$view = new Zend_View();
$view->setScriptPath('./views/');
$view->a = 'asdf';
echo $view->render('example.php');
?>

Taki oto kawałek kodu jesteśmy smuszeni umieścić w kodzie akcji by uruchomić widok. Gdzie jest wygoda, automatyczne uruchamianie widoku? Nie wspomnę już o tym, że w ten sposób Zend znacząco ogranicza możliwości zmiany warstwy obsługującej widok.

Wzorowym rozwiązaniem dla mnie jest użycie Render’ów, które świetnie się spisują do tworzenia outputu. Nie czepiam się tutaj braku takich elementarnych rzeczy jak konfiruacja, której praktycznie nie ma. Być może ktoś stwierdzi, że można to sobie zaimplementować, ale przepraszam, po co biorę framework? Po to by jak najmniej implementować, by tworzyć logikę biznesową a nie rozszeżać framework.
Elementem, który został obsłużony w ZF niecodziennie są filtry. Są one traktowane jako pluginy. Może i dobrze, ale co oprócz filtrów może być wykonywane przed akcją?
Bardzo mnie boli brak konkretnego flowa, narzuconego z góry. Przyznam, że podoba mi się taki standard ponieważ przyzwyczaiłem się do tego korzystając z Mojavi i Symfony.
Komuś odpowiada swoboda? W kodzie nie ma miejsca na swobodę. Im więcej możliwych dróg tym więcej możliwych błędów. Babranie się w ścieżki i tak dalej, po co to komu? Po to by móc rozdzielać sobie aplikację na mniejsze “moduły” a te na jeszcze mniejsze akcje? Skoro tak to dlaczego Zend_Controler_Front nie działa w katalogu innym niż document root? Ano dlatego, że panowie, którzy pisali Zend_Controler_Router twarto stwierdzili, że ich adres jest stały i ma format /controller/action. A co w przypadku kiedy mam index.php/controller/action? Otóż moim kontrolerem nie będzie controller a index.php. Nasz adres ogranicza się tylko do REQUEST_URI, a to czy SCRIPT_NAME w nim się znajduje bądź jesteśmy w katalogu innym niż document root nie ma wpływu na działanie całości.

Co dziwne. Błąd (tak, to jest wcześniej wspomniany błąd) tkwi w repozytorium od początku, to znaczy od 26 marca, kiedy to [chyba] pierwsza wersja ZF pojawiła się na SVN. Nie muszę chyba przypominać, że w M4 takich wpadek nie ma? ;)
Bardzo wstrętny bug (który zgłosiłem), tym bardziej, że nie trafiłem jeszcze na oprogramowanie, które by leżało u mnie bezpośrednio w document roocie. Zwykle jest tak, że jak coś ściągam to wrzucam do podkatalogu i w nim prowadzę testy. By te testy przeprowadzić z ZF musiałem nieco się namęczyć.

Mam więcej uwag co do samego Zenda, ale o tym w kolejnej notce.. Jeśli ktoś szuka porządnej implementacji MVC, zapraszam do zapoznania się z notką Mojavi 4, z bliska.

I oto się stało. Pierwszy raz użyłem przestrzeni nazw w PHP! Nie do wiary? A jednak. Nie było jakichkolwiek problemów z samą instalacją, ponieważ do pobrania jest paczka (pod Win ;)), która zachowuje się jak wszystkie inne pobrane z php.net. Przykłady podane na necie działają, więc nie pozostaje nic innego jak zabrać się za używanie przestrzeni nazw. :)

Oto listingi, które działają:

< ?php

import class a:::AFactory;
import class a:::A;

namespace a {
class AFactory {
public static function create() {
return new A;
}
}
private class A {}
}

// works perfectly:
AFactory::create();

// fails with 'Fatal error: Cannot use class 'a:::A' outside of its namespace, as it is private'
// new A;

?>

Oraz:

< ?php

import namespace a;

function __autoload($classname) {
foreach (get_imported_namespaces() as $ns) {
$filename = str_replace( ':::', '/', $ns ) . '/' . $classname . '.php';
if (file_exists($filename)) {
require_once($filename); // will require a/A.php
autoload_import_class($classname, $ns); // will import class a:::A
}
}
}

new A;

?>
// file a/A.php:
< ?php

namespace a {
class A {}
}

?>

Więcej informacji http://phpnamespaces.org/