Nowości z php.internals – widoczność klas

Jarrod Nettles w niedawnym wpisie na php.internals zgłosił propozycję wprowadzenia modyfikatorów widoczności dla klas. Propozycja postuluje, by podobnie jak w przypadku elementów klas (właściwości i metod), mieć możliwość ograniczenia widoczności klasy względem przestrzeni nazw. Jak miało by się to odbywać ? Przed deklaracją klasy można by umieścić jedno ze słów kluczowych – public, internal, lub private (albo public, protected, private):


private class Foo {
    private $_bar;

    public function bar(){
        return $this->_bar;
    }

}

Działanie:

  • public – obecny stan, posiadają bo również klasy bez zdefiniowanego modyfikatora
  • internal – klasa może być tylko wywoływane z tej samej głównej przestrzeni nazw, czyli jeżeli zdeklarujemy ją np. w Foo\Bar, to możemy ją również używać w Foo\Baz
  • private – klasa może być tylko wywoływana z tej samej przestrzeni nazw, czyli, jeżeli zdeklarujemy ją w Foo\Bar to mogę ją tylko używać w Foo\Bar i nigdzie indziej

Nie jest to ostateczny kształt propozycji, ponieważ, cały czas trwają dyskusje na ten temat na liście. Także to co napisałem może się jeszcze zmienić. Natomiast generalnie widać, że raczej większość osób jest jej przychylna. Na pewno ten „ficzer” będzie pomocny dla autorów frameworków, którzy będą mogli bardziej precyzyjnie kształtować API swoich bibliotek. Nie trudno również zauważyć, że propozycja ta jest tak naprawdę ściągnięta z języków typu C# i Java, gdzie takie modyfikatory dostępu już istnieją od dawna. Ze swojej strony mogę tylko powiedzieć, że osobiście wole model obiektowy oparty na bardziej ogólnym mechanizmie (świetnym przykładem jest Javascript).

Jestem ciekaw co Wy myślicie o tej propozycji ?

  1. Robert Gawron pisze:

    Hej, ale jeśli API jest spójne i udokumentowane, to użytkownicy powinni się orientować, które klasy mogą używać, a które są częścią wnętrzności =)

    Podobne podejście mam do tych modyfikatorów w kontekście metod klasy (BTW. fajne jest podejście z „_” z Pythona) lub modyfikatora finall dla klas Javy.

  2. @robert: zgadzam się z tobą w zupełności. Myślę, że to po prostu zależy od poziomu kultury programistycznej, jeżeli bibliotekę targetuje się do ludzi słabo rozgarniętych to niestety trzeba ich bić po rękach przy pomocy tych wszystkich modyfikatorów. Natomiast cała reszta jest na tyle rozgarnięta, że sobie poradzi i bez nich.

  3. batman pisze:

    Jak na początku cieszyłem się, że do PHP zaczynają wchodzić dobre rozwiązania, tak teraz zaczyna mnie to śmieszyć. Szczerze powiedziawszy wolę użyć innego języka, który ma to od dawna i nie jest tak zabałaganiony. Znając życie okaże się, że zostanie wprowadzony kolejny magiczny separator lub inna zabawna konstrukcja, np. selfNamespace i zrobi się jeszcze większe bagienko. Zamiast dodawać nowe rzeczy, wzięliby się za uporządkowanie języka.

  4. @batman: niestety, żeby uporządkować język, cokolwiek by to miało oznaczać, to trzeba by pewnie połowę rzeczy wywalić, co oznaczało by koniec PHP, bo jak wiemy, kompatybilność wsteczna jest tutaj kluczowa…

  5. zegarek84 pisze:

    prędzej by dali jakieś większe wsparcie na zdarzeniówkę, a dokładniej przepisali by kilka modułów by mogły działać asynchronicznie i opcjonalnie by wykonywały callbacki… implementacja asynchornicznych procesów [nie chodzi mi o forkowanie procesów] jest minimalistyczna i opiera się głównie na socketach gdzie trzeba wszystko samemu to obudowywać [lub skorzystać z rozwiązania gearman – które defakto też komunikuje się za pomocą socketów pomiędzy procesami]… do tej pory natywnie dopiero chyba tylko w php 5.3 z mysql można się połączyć asynchronicznie – problemu nie ma, gdy wszystko stoi na jednym kompie, gorzej jeśli trzeba się komunikować z innymi serwerami… przykładów można by mnożyć i wymieniać wiele wąskich gardeł…

    choć suma sumarum php często jest zaprzęgany do grubszych rzeczy niż powstało [przez co nawet tworzenie deamona/serwera działającego stale w php napotyka wąskie gardła gdzie problemem nie jest kompilacja kodu – który w końcu już jest uruchomiony], forkowanie procesów też jest dosyć kosztowne ale newet i to trzeba obudowywać – a wszystko robione tylko po to by samemu obejść ograniczenia możliwość asynchronicznych zdarzeń ;/

  6. @zegarek: myślę, że jak masz „coś grubszego” to warto użyć innych rozwiązań. Jest tyle technologii, które dużo lepiej się nadają do takich zastosowań niż php, nie ma co go wszędzie wtłaczać.

  7. KKH pisze:

    Tylko, że takie wtłaczanie czasem ma bardzo obiektywny powód: coś miało być małe, a sie rozrosło. Coś miało być niskobudżetowe a odniosło sukces. Coś miało trwać krótko, a trwa długo. PHP nie jest wyjatkiem tutaj.

  8. @kkh: różne są strategie zarządzania projektem. Natomiast, jeżeli coś potrzebuje być tak dużego, że potrzebuje rzeczy o których pisał zegarek, to na pewno właściciel tego czegoś ma na tyle kasy, żeby zafundować sobie migrację całości lub części, która nie wyrabia…

  9. deallas pisze:

    Pomysł dobry, ale zerżnięty. Ciekaw jestem czy pojawi się możliwość zagnieżdżania klas

    Btw, wie ktoś może kiedy pojawi się jakaś alpha PHP 5.4 ?

  10. O zagnieżdżaniu klas jak dotąd nie było mowy. Poza tym z tego co słyszałem to nie polecają stosowania inner classes w Javie. Co do wersji alpha to mieli ją wydać na końcu zeszłego roku ale nie doszli do konsensusu co jej kształtu. Natomiast zawsze można ściągnąć i skompliować aktualny trunk.

  11. KKH pisze:

    @Wojciech Soczyński on 10 mar 2011 at 14:07 #

    Startup zaskoczony własnym sukcesem może nie mieć kasy. ba! Nawet uznany gigant może cierpieć na brak płynności finansowej. To sprawa indywidualna.

    Migaracja migracji nierówna, bo tu np. nie zmieniamy komponentu, a przepisujemy całość na zupełnie inny język. Może się okazać, że w zespole nie masz ludzi znających tą „lepsza” technologię. Szkolisz, ogłaszasz rekrutację, piszesz wszystko od nowa. A stary kod w tym czasie leży martwy? Nie sądzę.

    I to wszystko bardzo często w warunkach kredytu albo świecenia oczami przed inwestorami: „wicie rozumicie panowie. Dziękuję za te kilka milionów, ale zaprawdę powiadam wam: na razie zysków nie ma, ale będa one niebotyczne, jak dołożycie jeszcze drugie tyle, bo zawidziało mi się przepisać projekt na inny język.”

    Nie teortyzuję. np. Facebook brnął w PHP aż miło, nawet HipHopa zrobili w ramach tego brnięcia.

    Poza tym można rozważać zasadność sztucznego ograniczania języka do jednego zastosowania. PHP ma fajną niszę, OK. Ale jaki jest sens istnienia tego języka gdy jakiś inny język w niszy PHPowej będzie równie dobry co PHP, a ponadto zaoferuje tuzin innych zastosowań?

  12. KKH pisze:

    @Wojciech Soczyński on 10 mar 2011 at 12:38 #

    Kompatybilność wsteczną i minimzalizację ryzyka nieprzyjęcia się zreformowanego PHP można spokojnie załatwić forkując projekt na dwie gałęzie: konserwatywną i przyszłościową. Po prostu społeczność php nie ma ludzi do tej roboty i tyle.

  13. @KKH, to fakt, że nie ma ludzi, ale z drugiej strony to co zauważam, to wielkie problemy z osiągnięciem konsensusu nawet przez tą garstkę, która coś majstruje przy wnętrznościach. Jeżeli mamy projekt OS liderowany przez jakąś organizację to nie ma problemu, ktoś sponsoruje to nadaje ton pracom. Natomiast gdy mamy tylko grupkę pasjonatów to niestety ciężko jest się zgodzić z rewolucyjnym zmianami, kiedy każdy ma diametralnie inne poglądy.

  14. batman pisze:

    @Wojciech Soczyński
    I tutaj dochodzimy do sedna problemu. Jeśli za PHP stałaby jakaś organizacja, która potrafiłaby krótko trzymać głównych deweloperów, wówczas PHP nie byłby pośmiewiskiem, a gimnazjalista nie byłby synonimem programisty PHP.

  15. @batman: ja myślę, że problem niedługo sam się rozwiąże. Już teraz PHP traci popularność. Gdy ją straci znacząco, to na zwykłych wirtualnych serwerach zaczną się pojawiać też inne technologie. To będzie gwóźdź do trumny PHP. O ile oczywiście chłopaki się nie otrząsną. Może założą jakąś fundację na wzór „Python Foundation” ?

  16. batman pisze:

    Szczerze wątpię, by domorośli admini z firm hostingowych chcieli/umieli instalować coś innego. Bardziej prawdopodobnym scenariuszem będzie powrót PHP do korzeni, czyli do dynamicznych stron. Rolę języka do tworzenia aplikacji internetowych przejmie inna technologia.

  17. Rozumiem, że mówisz o Polsce ? Bo z tego co zauważam, to na zachodzie już od jakiegoś czasu większe projekty powstają tylko przy użyciu czegoś z tria Rails/Python/ASP.net plus świeże technologie w rodzaju Clojure/Scala …

  18. batman pisze:

    Tak, chodzi mi o Polskę. Chociaż u nas też można zauważyć, że w nowych projektach powoli odchodzi się od PHP.

  19. Mimo, że jestem fanem PHP, uważam, że to dobrze. Czym więcej projektów w innych technologiach tym więcej ciekawych ofert pracy, a czym ciekawsze oferty, tym łatwiej można się rozwijać :)

  20. Artur Świerc pisze:

    @Wojciech Soczyński jednym słowem, wpakowaliśmy się w bagno i teraz trudno z niego wyjść – zarabiać trzeba, a zatrudnienie się teraz jako „Junior Java Programmer” to kiepskie rozwiązanie :)

  21. @Artur: nie wiem jak ty, ale ja nigdy nie zakładałem, że do końca życia będę pisał w PHP, ba, nawet, że zawsze będę programistą. Warunki na rynku się zmieniają i trzeba się dostosować. Zatrudnienie się jako Junior Java Programmer w dużej korporacji nie jest złym wyjściem. Zarobki mam wrażenie, że podobne jak dla doświadczonego PHP-owca…

  22. Artur Świerc pisze:

    Oczywiście, trzeba się rozwijać. Od paru lat programuję hobbystycznie w javie, ale bez udokumentowanego, komercyjnego doświadczenia nie ma co szukać w tym światku. Czytam blogi ludzi, którzy nieźle się nagimnastykowali aby przesiąść się z PHP na Javę – co świadczy o tym, że programiści PHP w Polsce są traktowani jako coś gorszego. (tutaj wspomnę, że podobają mi się Twoje przykłady kodu w PHP np na GL. A niech inni zobaczą jak można pisać w tym języku :))

    Najlepszym rozwiązaniem jest, gdy firma w której programista PHP pracuje, się rozwija, uznaje że pora zacząć robić coś innego niż sklepy – inna technologia, nowi ludzi, nowe doświadczenie a firma ta sama :)

  23. To jest optymalne, gdy można w jednej firmie zacząć nabywać doświadczenie w innej technologii. Jednak chyba trzeba trafić na odpowiedni moment albo samemu zainicjować taką migrację, o ile się ma siłę przebicia…

  1. There are no trackbacks for this post yet.

Leave a Reply

Informuj mnie o odpowiedziach poprzez e-mail. Możesz również subskrybować wpis bez zostawiania komentarza.