Kanał ATOM
Autor wpisu: sokzzuka, dodany: 16.10.2010 23:01, tagi: php
Jeżeli śledzicie dzone.com. Pewnie zauważyliście, że od pewnego czasu na blogach osób związanych z Java’ą przetaczają się dwa związane ze sobą tematy. Pierwszym z nich jest kwestia uczynienia Java’y wolną (udostępnienie jej na wolnej licencji, uniezależnienie od Oracle) a drugim z nich jest kwestia zmian w języku. Kilka osób poddało pomysł aby zrobić fork Java’y wydany na jednej z licencji open-source’owych. Co do zmian w języku to część osób rozczarowana tym jaki kształt ma w tej chwili język oraz powolnym wprowadzaniem nowości do niego doszła również do wniosku, że najlepiej było by stworzyć nową wersję Java’y niekompatybilną wstecznie (Backward Incompatibile) Java. Znalazło się jak to zwykle bywa sporo osób, które stwierdziły ze oba pomysły jak najbardziej idą ze sobą w parze i proponują stworzenie „wolnego” fork’a Javy i rozwijanie go w sposób niekompatybilny wstecznie. Mnie nasuwa się jedynie pytanie, czy taki fork dalej będzie (i będzie można go nazywać) Java’ą ?
Postanowiłem odnieść tą sytuację do własnego podwórka i zastanowić się co by było gdyby stworzyć fork interpretera PHP. Jakie zmiany ja przeprowadziłbym w języku i dlaczego oraz czy po tych zmianach ten fork można by nazwać jeszcze PHP. Zachęcam też wszystkich do zabawy i wpisywania własnych propozycji. Jedną z pierwszych rzeczy jaką był zmienił, to usunięcie przestarzałych rzeczy typu register globals, short open tag, magic quotes, safe mode, allow call time pass by reference.
Drugą rzeczą było by przejrzenie pliku php.ini i usunięcie wszystkich opcji, które w jakikolwiek sposób niejawnie wpływają na wykonywanie skryptów – banowanie klas, funkcji etc. Domyślam się, że po tej operacji, zostały by tylko opcje związane z włączaniem/wyłączaniem rozszerzeń oraz limit czasu i pamięci.
Trzecią rzeczą było by zastąpienie wszystkich error’ów wyjątkami (z wyjątkiem parse_error i compile_error z wiadomych względów).
Zmiany omówione jak narazie w zasadzie nie zmieniają samej istoty języka a tylko sposób działania interpretera. Dalsze rzeczy jednak już jak nabardziej.
Po czwarte usuną bym słowa kluczowe i mechanizmy: global i goto. Są to pozostałości po językach bardziej niskopoziomowych i zwykle po prostu zaciemniają kod. Co więcej, pisząc w sposób obiektowy, nie ma w ogóle potrzeby ich wykorzystywania.
Po piąte – biblioteka standardowa. Zamiast jednej globalnej przestrzeni nazw przesunął bym funkcje z różnorakich rozszerzeń do własnych namespace’ów.
Po szóste – typy proste. Typy proste zamieniłbym na obiekty, które dziedziczą z klasy ‘Value’. Obiekty których klasy dziedziczą z klasy ‘Value’ były by nie zmienialne (immutable) oraz przekazywane przez kopię. Obiekty użytkownika, które dziedziczyły by z abstrakcyjnej klasy Value mogły by też same obsługiwać rzutowanie (funkcja typu __cast).
Po siódme zmiana orientacji języka na bardziej funkcjonalno-obiektowy niż proceduralno-obiektowy. Usunięcie możliwości przekazywania przez referencje typów prostych – konsekwencja punktu szóstego.
Po ósme – anonimowe klasy i obiekty oraz obiekty typu singleton jak w Scala’i oraz usunięcie możliwości deklaracji statycznych metod i pól klasy.
Kto by przypuszczał, że Zend Framework 1.11 wniesie tyle świeżości.
