The Explorer

Moriyoshi Koizumi przedstawił wczoraj popołudniu propozycję wbudowania do php-cli deweloperskiego serwera www. Powstała propozycja RFC wraz z patchem dostępnym na githubie. Jak dotąd propozycja spotkała się z pozytywnym przyjęciem na liście dyskusyjnej.

Ogólnie zamysł jest taki, by można było szybko przygotować sobie środowisko deweloperskie korzystając tylko z dystrybucji PHP, bez konieczności instalowania apache, czy innego webservera. Jest to bardzo podobna strategia, jak ta stosowana np. we frameworku Django dla Pythona. Jak na razie możliwości tej implementacji sprowadzają się do nasłuchiwania na wybranym porcie żądań od przeglądarki, ustawienia „document roota” i definiowalnego w zewnętrznym pliku php routingu.

Osobiście propozycja mi się bardzo podoba, a jakie jest Wasze zdanie :> ?

Jak już było wczoraj zapowiedziane. Do ściągnięcia jest najnowsza wersja Release Candidate PHP – 5.3.6RC1. Jest to Release Candidate, a więc nie należy jej używać na produkcji. Kolejny RC albo finalna wersja pojawi się prawdopodobnie za około dwa tygodnie.

• Źródła dla Linuxa: http://downloads.php.net/johannes/php-5.3.6RC1.tar.bz2
• Binarki dla Windows: http://windows.php.net/qa/

Źródło: http://news.php.net/php.internals/51453

Johannes Schlüter (release manager dla brancha 5.3.x) zapowiedział dzisiaj wydanie PHP 5.3.6 w wersji Release Candidate na czwartek 17-tego lutego. Wszyscy chętni do testowania otrzymają więc jutro świeżą porcję kodu

Marcin Babij z naszej klasy w swoim wpisie na php.internals poinformował społeczność php, o wykonanych przez nich optymalizacjach interpretera. Dotyczą one implementacji hash table czyli znanych nam wszystkim php-owych „arrayów”. Jako, że są one wykorzystywane wszędzie, nie tylko w kodzie napisanym przez użytkowników ale również w wielu miejscach w samym interpreterze, każda poprawka, która przyspiesza funkcje operujące na tej strukturze danych jest mile widziana (jak podaje Babij średnio ich wywołania zajmują 10%-20% czasu każdego skryptu).

Nie wgłębiając się zbytnio w techniczne szczegóły, które można znaleźć w oryginalnym wpisie, programistom nk.pl udało się zmniejszyć obciążenie procesora przy operacjach na tablicach o 4% do 6% przy niewielkim wzroście użycia pamięci. Patch, który dostarczył został sprawdzony względem php 5.3.4 i apc-3.1.3p1 i można go ściągnąć z githuba.

Wypada tylko podziękować programistom naszej klasy, że są tak uprzejmi i dzielą się swoimi osiągnięciami. Może to zachęci inne osoby z naszego pięknego kraju do przyłączenia się do projektu.

Kilka dni temu, Mathias Grimm, zgłosił na grupie php.internals propozycję dodania makr preprocesora do PHP. Miały by działać one analogicznie jak te w C, z wyjątkiem tego, że były by deklarowane za pomocą funkcji MACRO(‚nazwa_makra’,’jakas_tresc_makra’). Propozycja nie spotkała się raczej z entuzjastycznym przyjęciem. Oponenci argumentowali, że z racji na dynamiczną naturę języka dodanie makr nie wnosi żadnej nowej jakości i tylko zaciemnia kod dla osób nie zaznajomionych z nim. Wobec tego propozycja raczej nie przejdzie, chociaż widzę, że dyskusja się dość rozwinęła. Przy okazji tej dyskusji wyszło kilka ciekawych rzeczy, np. że jest rozszerzenie o nazwie „prep„, które tą obsługę wprowadza natywnie, oraz również mająca podobną funkcjonalność implementacja w czystym php. Z innych wartych odnotowania spraw, dowiedzieć się można, że używa się też gcc do takich rzeczy w formie:

<?php
#define PF private function
#define SCOPE_CLASS(x) class MyProject_ ## x

class UseMacro
{
     PF preSave($object)
     {
        //...
     }

}

SCOPE_CLASS(Internal)
{

}
?>

taki kod następnie należy przepuścić przez gcc komendą:

gcc -Mcpp -E - - < in.php > out.php

Widać kreatywność ludzka nie zna granic. Tak czy inaczej, ja osobiście uważam, że makra w php są zbędne, natomiast sądzę, że zamiast nich przydało by się wsparcie api dla rzeczy, które w tej chwili wykonuje się przy pomocy evala, np. anonimowe klasy, czy dynamiczne proxy.

Ciekaw jestem, jakie jest Wasze zdanie na ten temat ?