Nowości z php.internals – annotation strikes back

Od czasu rozpoczęcia się wątku o PHP 5.4 na liście php.internals, jak bumerang powrócił temat adnotacji. Nasi drodzy deweloperzy doszli do nowego konsensusu (poprzedni odrzucał adnotację) i stwierdzili, że może nie są jednak one takie złe. W efekcie tego powstała nowa propozycja RFC, główne zmiany jakie w niej widzę, to zmiany składniowe (o które były największe bitwy ostatnim razem). W nowej propozycji adnotacje mają postać miksu phpDoc i formatu JSON. Nowa składnia behold:

/**
 * Foo class.
 *
 * @Entity {repositoryClass: "FooRepository"}
 * @Table  {name: "foos"}
 *
 * @author "Guilherme Blanco"
 */
class Foo
{
  // ...
}

Na pierwszy rzut oka zdaję się być kompatybilna z istniejącym rozwiązaniem (phpDoc). Jednak wszystko zależy od konkretnej implementacji parsera. Wykorzystanie:

$reflClass = new \ReflectionClass('Foo');
var_dump($reflClass->getAnnotations());
 
/*
array(3) {
  ["Entity"]=>
  object(ReflectionAnnotation)#1 (1) {
    ["value"]=>
    object(stdClass)#1 (1) {
      ["repositoryClass"]=>
      string(13) "FooRepository"
    }
  }
  ["Table"]=>
  object(ReflectionAnnotation)#2 (1) {
    ["value"]=>
    object(stdClass)#1 (1) {
      ["name"]=>
      string(4) "foos"
    }
  }
  ["author"]=>
  object(ReflectionAnnotation)#3 (1) {
    ["value"]=>
    string(16) "Guilherme Blanco"
  }
}
*/

Propozycja będzie jeszcze pewnie wiele razy dyskutowana, oczekujcie więc więcej informacji z tego pola bitwy 😉

  1. Crozin pisze:

    Czy to tylko moje wrażenie czy PHP i jego społeczność dążą do zostania taką kulawą Javą? Nie widzę niczego złego w korzystaniu ze sprawdzonych rozwiązań, ale język sam w sobie kopiuje Javę fragment po fragmencie jedynie dostosowując założenia kopiowanych fragmentów do dynamicznego charakteru języka. Również wiele bibliotek / projektów jest pisanych jako ubogie klony tych ze świata Javy.

  2. No niewątpliwie jest duża inspiracja Javą, ale nie tylko, również .net (c#) ma pewien swój udział. Czy chcemy tego czy nie to pomysły przemieszczają się w tym ekosystemie między językami.

  3. Szymek pisze:

    @Crozin: Od dawana da się zaobserwować taka tendencję, ale nie uważam jej za coś złego. Sam z resztą napisałeś o sprawdzonych rozwiązaniach, którymi moim skromnym zdaniem adnotacje są. Mi osobiście one bardzo przypadły do gustu i od pewnego czasu używam ich namiętnie podczas pracy z Symfony2 i Doctrine2. Nawiasem mówiąc Symfony2 od początku przypominał mi nieco javowego Springa i nie sądzę aby można uznać to za jego minus.

  4. batman pisze:

    Nie mam nic przeciwko kopiowaniu sprawdzonych rozwiązań. Niestety w przypadku PHP tzw. ekipa nie może dojść do porozumienia i ustalane są kompromisowe rozwiązania nie zawsze pokrywające się ze zdrowym rozsądkiem.

    P.S.
    Wprowadzenie adnotacji do PHP jest świetnym pomysłem. Mam nadzieję, że nie będzie „jak zwykle”.

  5. Ja także popieram wprowadzenie annotacji – wygląda to na sprawdzone rozwiązanie, tym bardziej, że tak jak batman uważam, że jeśli coś działa dobrze, to możemy to „zainkorporować” we własnym ekosystemie. Gorzej, jeśli PHP zacząłby w pewnym momencie realizować te funkcjonalności, na które programiści Javy czy C# narzekają.

  6. Ja czasami jak widzę co chłopaki na internalsach wyczyniają to mam ochotę albo zrobić fork PHP albo napisać sobie własny język ;P

  7. matipl pisze:

    @Crozin: czemu nie naśladować dobrych wzorców?
    Poza tym z Javy nie wszystko da się swobodnie przenieść, bo działanie jest uzależnione od danego języka.

  8. @matipl – moim zdaniem trzeba mieć wizje tego co chce się osiągnąć, małpowanie ma sens ale na krótką metę, jeżeli bierzemy pomysły z różnych miejsc to potem może nam powstać niezły „burdel” ;). Oczywiście nie mam nic przeciwko naśladownictwu ale musi to być przemyślane.

  9. matipl pisze:

    @wojtek: eee, wzorce projektowe to też małpowanie? OOP?
    Z dobrych wzorów należy korzystać, jasne że często PHP Team wali z grubej rury, ale rozchodzi się po kościach i ost. wychodzą ciekawe nowości..

  10. @matipl: wzorce projektowe są czymś ponad językami programowania. Natomiast frameworki Javowe też mają swoje ułomności i problem się pojawia kiedy, ktoś nie zdaje sobie z tego sprawy, kopiuje jakieś rozwiązanie i uważa potem, że jest zaje****e 😉

  11. Jasne, że nie można nic kopiować na małpę, bo będzie to tylko „przypominało” oryginalne rozwiązanie, które może i działa, ale tylko pod pewnymi warunkami.

    Ja widzę problem w tym, że PHP jest dla zdecydowanej większości jego programistów zupełnie wystarczający i wcale nie interesuje ich wprowadzanie czegoś nowego. Właściwie jedyne osoby, jakie faktycznie odczuwają braki to twórcy bibliotek i frameworków. Ich praca polega zresztą na inteligentnym ukrywaniu niewygodnych [czyt. niezrozumiałych dla typowego programisty] funkcjonalności języka.

    @Wojciech Soczyński: Obserwuję Twoje wpisy o php.internals i skłaniają mnie one coraz bardziej do samodzielnego śledzenia tych nowości, a także publikowania swoich opinii na ten temat. Nie chcę jednak kopiować ;] Twojego pomysłu, dlatego pozwolisz, że zapytam, co o tym sądzisz?

  12. @Tomasz: myślę, że to świetny pomysł. Jednym z celów jaki sobie postawiłem publikując te wpisy było to, żeby zainteresować rozwojem języka „szarego” programistę. Żeby ta społeczność pehapowa zaczęła bardziej żyć. Bo przyznam ze smutkiem, że społeczność Rubiego czy Pythona jest dużo bardziej prężna i bardziej angażuje się w rozwój samego języka, jak również i bibliotek. Dlatego też myślę, że czym więcej będzie się działo tym lepiej. Również chętnie przeczytam Twoje analizy tego co się dzieje na tej liście.

  13. Ok, zapisałem się do grupy – czekam na nowości. BTW. Polecasz jakieś inne grupy php.*? Bo na serwerze news.php.net trochę ich jest. ;]

  14. Artur Świerc pisze:

    Tylko czekałem kiedy wątek powróci.

    To że składnia będzie phpdoc to wg mnie straszne lenistwo twórców języka. Wydaje mi się, że wychodzą z założenia – dajmy im jakąkolwiek obsługę adnotacji, niech nam dają spokój. Problem jest, ponieważ coraz więcej bibliotek i frameworków w php chce z tego korzystać, i tworzą swoje protezy w phpdoc.
    Do tego dochodzi oczywiście konkurencja innych języków – java, c# czy python dawno taką funkcjonalność oferują.

    Swoją drogą dlaczego zrezygnowali z tej wersji ‚si-szarpowej’ – bo chyba taka kiedyś wisiała na RFC?

  15. @Artur: chodzi o zachowanie jak największej kompatybyilności z istniejącymi rozwiązaniami i nie wprowadzaniu nowej składni do obsługi przez parser.

  16. @Tomasz: ja oglądam tylko internals, bo tam generalnie chyba są najciekawsze rzeczy…

  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.