Nowości z php.internals – __autodefine

W jednym z ostatnich wpisów na internalsach, Loon var Reinier zgłosił propozycje RFC pt. ‘__autodefine’. Postuluje ona generalizację mechanizmu autoloadera i rozszerzenie go również m.in o funkcje, stałe i przestrzenie nazw. Polegałby on na zdefiniowaniu funkcji __autodefine o parametrach ($nazwa, $typ), gdzie $nazwa to nazwa brakującego elementu, natomiast $typ to jedna ze stałych w rodzaju T_FUNCTION, T_CONST etc. Jako uzupełnienie funkcji __autodefine proponowane jest dodanie również funkcji spl_autodefine_register o działaniu analogicznym do spl_autoload_register.

Osobiście uważam, że pomysł jest dobry i przydatny. Jestem tylko zdania, że zarówno mechanizm autoload jak i autodefine powinien być używany tylko per przestrzeń nazw, aby uniknąć konfliktów.

A wy co o tym sądzicie :> ?

  1. Alan Gabriel Bem says:

    Czyli co? Tyle zachodu, żeby zobiektywizować PHP, a oni wyskakują z czymś takim?
    żenua

  2. Po pierwsze nie “oni” tylko jakiś niezwiązany deweloper. Po drugie, php jest językiem multiparadygmatowym i uważam, że np. wsparcie dla autoładowania funkcji czy przestrzeni nazw jest potrzebne. Po trzecie php to nie JAVA i nie musimy wszystkiego na siłę wciskać do obiektów (wrapować pojedyncze funkcje etc).

  3. batman says:

    Kiepski pomysł. Teraz w sytuacji, w której nie ma czegoś zdefiniowanego, dostajemy przynajmniej notice. Jak wprowadzą proponowaną magiczną funkcję, nic nie będzie leciało do logów i nawet nie będzie wiadomo, że aplikacja nie działa tak jak powinna.
    Jeszcze trochę i PHP będzie miał tylko funkcje __autoxyz :)

  4. @batman:
    No a jak działa autoload ? Jeżeli w wyniku jego działania nie zostanie wprowadzona żadna klasa, to wychodzi nam błąd. Tutaj było by tak samo, więc uważam, że nie masz racji w tej kwestii.

  5. batman says:

    Autoload ma za zadanie zdjąć z programisty durny obowiązek ręcznego dołączania plików. Autodefine spowoduje, że każdy niezdefiniowany byt będzie leciał do tej funkcji, podobnie jak ma to miejsce np. w przypadku __call lub __set. Jeśli sam nie zadbasz o sprawdzenie, czy konkretna wartość może być wywołana/zapisana, to nie wiesz, że wpadła niepoprawna.

  6. @batman:
    Autoload używa się jeszcze do innych rzeczy, jak np do generowania klas “w locie” (np. proxy etc). Moim skromnym zdaniem, jest to po prostu kolejny ficzer, który jest przydatny ale trzeba go używać z rozwagą…

  7. batman says:

    Nie podoba mi się ten kierunek rozwoju. Odnoszę wrażenie, iż te wszystkie magiczne funkcje i metody mają na celu leczenie kompleksów PHP, a nie realną poprawę języka.

  8. Mi też się nie podoba to rozwiązanie. O ile cel autoloadingu jest w miarę sprecyzowany, o tyle autodefine nie ma żadnego sensownego zastosowania. Jeśli ktoś zapomina używać stałych, może czas zapakować je w jakąś klasę z deklaracjami const?

  9. Zyx says:

    Co rozumiesz pod pojęciem “ładowania przestrzeni nazw”? Przestrzeń nazw to tylko alias, w PHP nie ma czegoś takiego, jak “ładowanie przestrzeni nazw”.

  10. Moim zdaniem, ładowanie przestrzeni nazw to sytuacja taka, w której np. na początku pliku importujemy namespace (use My\Full\Name), natomiast nie została ona jeszcze nigdzie wcześniej zdefiniowana. Wobec tego odpowiednie pliki muszą zostać zainkludowane ( z deklaracją namespace’u). Efektywnie ficzer sprowadza się do funkcjonalności podobnej jak “import” statement w Javie. Natomiast szczerze to powiem Ci, że nie jestem pewien czy to samo miał autor propozycji na myśli…

  11. Zyx says:

    W PHP nie ma czegoś takiego, jak “import/autoładowanie/wczytywanie/cokolwiek się z tym wiążącego” przestrzeni nazw. Komenda USE tworzy ALIAS i nie wiąże się z tym żadne ładowanie, weryfikacja poprawności itd.

  12. No to mówie, że nie ma, ale defakto tak by to działało…

  13. eRIZ says:

    Nie no, dla mnie to trochę przesada – w ten sposób ze stałych robi się zmienne na sterydach…

    Jeszcze większy chaos niż jest; mogliby wreszcie dodać do core’owych funkcji wypluwanie wyjątków, a nie zajmują się pierdołami…

    IMHO by to było z większym pożytkiem niż jakaś nowa funkcja, która często będzie mało użyteczna…

  14. Każdy ma tam swoje wizje :> co dobitnie wykazały komentarze pod wpisem Co by było gdyby… dlatego w sumie rozważam kiedyś napisanie jakiegoś małego języka, który oddawałby moje przemyślenia :>

  1. There are no trackbacks for this post yet.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.