Nowości z php.internals – bitwa o adnotacje

Sprawa adnotacji wywołała dość duże poruszenie na liście php.internals. Uformowały się trzy grupy dyskutantów – jedna popierająca adnotacje, druga uważająca, że jest to zupełnie nie potrzebne i komplikuje język i trzecia która stara się znaleźć kompromis.

W wyniku dość długiej dyskusji, skrystalizowało się kilka wniosków – po pierwsze adnotacje nie powinny wprowadzać żadnej nowej składni ponad zaznaczenie, że dana część kodu jest adnotacją, czyli coś w rodzaju [kod php] gdzie „[” i „]” oznaczają początek i koniec adnotacji, natomiast jej treść jest poprawnym kodem php. Drugi wniosek jest taki, że grupa nr trzy stwierdziła, że skoro nie można dość do kompromisu w sprawie adnotacji, to może po prostu najlepiej by było wbudować parser phpDoc do mechanizmów refleksji. Trzeci wniosek, jest taki, że pewna część deweloperów nie widzi zastosowania dla adnotacji, co więcej nie wie nawet czym one są i dlatego uważa, że nie należy ich wprowadzać. Z innych ciekawych rzeczy, zauważyłem, że jest grupka deweloperów, którzy mają jakieś doświadczenie z Pythonem i chcieli by zmienić trochę PHP w jego stronę tj. wszystko jest obiektem (klasy, funkcje etc). Wtedy adnotacje mogły by być zastąpione przez Pythonowe dekoratory.

Ogólnie to zauważam dwa albo nawet trzy trendy a właściwie rodzaje ludzi którzy wypowiadają się na liście „internals”. Pierwszy z nich to ludzie, którzy przyszli z środowiska języka C i są raczej dość konserwatywni i nie chcą zbytnio zmieniać formy języka, mają podejście bardziej proceduralne. Drugą grupą są ludzie, którzy mają doświadczenia w Java’ie i C# i próbują przenieść niektóre cechy a nawet całą składnię z tych języków ich podejście to babilońska obiektówka w stylu EJB, czasami nawet dosłownie cytują jakieś dokumenty JSR Java’y. Trzecia grupa, to ludzie pochodzący z języków typu Ruby czy Python oraz języków funkcyjnych. Jest to chyba najmniejsza grupa, ich poglądy uważane są chyba za najbardziej kontrowersyjne wśród pozostałych dwóch grup i raczej niechętnie akceptowane.

Pytaniem na dziś jest więc, po pierwsze, co widzielibyście w przyszłości w PHP – adnotacje, czy wbudowany parser phpDoc, a może żadną z tych rzeczy ? Po drugie, w jakim kierunku powinien ewoluować język – w stronę Python’ową (wszystko jest obiektem, więcej cech języków funkcyjnych) czy może Java/C# ?

  1. Zyx pisze:

    Wbudowany parser do refleksji – najczęściej jedyne, co trzeba, to po prostu taką adnotację odczytać i nic więcej, a jak ktoś będzie chciał z tego generator kodu zrobić, to i tak zrobi.

    Adnotacje na poziomie parsera mają sens w językach takich, jak Java, gdzie kompilator jest jawnie i domyślnie oddzielony od maszyny wirtualnej, jako że są one przetwarzane w czasie kompilacji kodu źródłowego.

    Nie rozumiem natomiast jednego: po …. oni chcą zmieniać już ugruntowaną składnię adnotacji stosowaną przez phpDocumentor, Doctrine 2, Symfony, PHPUnit i dziesiątki innych projektów. :/

  2. batman pisze:

    Jak już wcześniej pisałem, pomysł bardzo mi się podoba. Powtórzę również moje obawy dotyczące adnotacji. Skoro PHP się nie kompiluje, to zastosowanie adnotacji może bardzo spowolnić aplikację, która z nich korzysta. W chwili obecnej nie wyobrażam sobie wprowadzenia tego mechanizmu do aktualnej wersji języka.

  3. @zyx

    +1

    Dostęp do składni phpdoca w refleksjach wystarczy. TO jest de-facto standard praktycznie we wszystkich większych projektach w PHP, a do tej pory np. PHPUnit musi borykać się z ręcznym parsowaniem tego.

  4. Wojciech Soczyński pisze:

    @zyx – z składnią jest ta kwestia, że jeżeli chcesz oddzielić adnotacje od komentarzy to taka adnotacja nie może być komentarzem, a jako że „@” jest zajęta na operator wyciszania, to musi być jakaś inna składnia.

    Adnotacje na poziomie parsera mają taki sam sens jak wbudowany parser phpDoc – zostaną zparsowane i możesz przy użyciu refleksji je odczytać, natomiast trzymanie adnotacji poza komentarzem jest o tyle lepsze, że po pierwsze komentarz z definicji nie powinien być parsowany a po drugie zdarza się dość często, że dla zwiększenia wydajności ludzie wycinają komentarze z kodu wraz z białymi znakami, wtedy nasze metadane opisane w phpDoc’u giną bezpowrotnie…

  5. starach pisze:

    A mógłby ktoś w prostych słowach powiedzieć co do diabła są adnotacje? Co one dają i do czego one służą?

  6. batman pisze:

    ~starach
    Najprostszy przykład wzięty żywcem z ASP.NET MVC.
    Masz kontroler, w którym znajduje się akcja odpowiedzialna za przechwycenie danych z formularza. Walidację danych, które trafiają do akcji robisz w adnotacji, dzięki czemu kontroler wie, że to co do niego trafiło jest ok/błędne.
    Inny przykład – ustawiasz w adnotacji, że dana akcja przyjmuje tylko dane POST. Wówczas nie musisz się zajmować dodatkową walidacją, ponieważ to robi adnotacja.

  7. @autor

    Trzymanie adnotacji w teorii powinno być poza komentarzem, ale IMHO w 2010 roku, w momencie, kiedy wszyscy korzystaja z phpdoc, dodanie supportu dla tej skladni (wewnątrzkomentarzowej) dało największy zysk dla całej społeczności.

    Jeśli ktoś wycina komentarze dla (calkowicie pomijalnego, a przy np. APC zerowego) wzrostu wydajności, to niech po prostu nie wycina tych z „@”. Kwestia modyfikacji jednego regexpa.

  8. Wojciech Soczyński pisze:

    @krzysztof

    z drugiej strony, dodanie tego jako nowej cechy języka żadnego kodu nie popsuje, natomiast myślę, że jest bardziej eleganckie od phpDoc’a w komentarzach…

  9. Zyx pisze:

    Nie zgodzę się, że musi to być oddzielone. Składnia komentarzy „phpdoc” jest powszechnie znana i akceptowana. Dotychczasowe autorskie parsery jakoś nie mają problemów z wykrywaniem adnotacji i nie widzę przeszkód, dla którego parser wbudowany w PHP nie miałby działać w ten sam sposób. W dodatku zachowana byłaby semantyka pasująca do PHP:

    – podczas normalnego wykonywania adnotacje są całkowicie olewane, ponieważ są w komentarzach.
    – jeśli korzystamy z refleksji do odczytu adnotacji, w tle może zostać odpalony parser, który ponownie przeskanuje dany plik i dopiero wtedy przeskanuje wszystkie komentarze phpdoc w poszukiwaniu adnotacji, które dopisze do atrybutów klas.

    Wtedy wilk jest syty i owca cała: adnotacje nie spowalniają PHP podczas normalnej pracy, cały dotychczasowy kod działa bez problemów, a my mamy wbudowany (i przezroczysty) parser.

  10. batman pisze:

    ~Zyx
    Twój komentarz przekonał mnie, że adnotacje w PHP nie mają sensu. Rozważmy dwie możliwości.

    1. Twój sposób. Do adnotacji dostajemy się na żądanie. W sumie nic się nie zmieni w stosunku do tego co jest obecnie. Trzeba będzie użyć specjalnych klas, by dostać się do adnotacji, a następnie wykonać ich kod. W tym przypadku można zapomnieć o jakiejkolwiek automatyzacji niektórych czynności (np wspomniana przeze mnie walidacja danych wejściowych).

    2. Adnotacje są z automatu przetwarzane. W tej wersji wypadałoby przepisać silnik PHP. Jeśli chłopaki z PHP się za to zabiorą, to prędzej wyjdzie oficjalna specyfikacja HTML5…

    Cóż. Fajnie było pomarzyć.

  11. Wojciech Soczyński pisze:

    @batman – czyżby marzyły ci się dekoratory a’la python ;p ?

  12. batman pisze:

    Nie znam pythona, więc nie odpowiem na Twoje pytanie.
    Po prostu jestem obecnie na etapie poznawania nowej technologii i na dzień dzisiejszy widzę, że nie ma ona wad, a to co używałem do tej pory ma same wady. Przejdzie mi :)

  13. Wojciech Soczyński pisze:

    @batman
    mówisz o ASP.MVC czy o czymś jeszcze inniejszym ?

  14. batman pisze:

    Chodzi mi o ASP.NET MVC + Silverlight i inne technologie Microsoftu, który najwyraźniej dostrzegł potencjał drzemiący w małych ludkach (Open Source) i stara się dotrzeć do tych ludków poprzez coraz lepsze rozwiązania.

  1. […] wiadomości z tego serwisu Follow us on Twitter 71 śledzących RSS Feed 358 czytelników Nowości z php.internals – bitwa o adnotacje 1 głosuj! Zmiany w php – propozycja dodania obsługi adnotacji    więcej […]

Leave a Reply

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