The Explorer

Pewnie kilka razy w życiu każdy z nas zetknął się albo i też używał operatora trójargumentowego znanego też jako “ternary operator” bądź “operator Elvisa” (skrócona wersja w Groovym, ciekawe kto wymyślił tą nazwę). Jest to skrócona składnia dla prostego przypadku “if” i wygląda on mniej więcej tak:

$foo = 5;
$bar = ($foo==5) ? "Foo równa się 5" : "Foo nie równa się 5";
echo $bar;

Najczęściej chyba operatora Elvisa używa się by sprawdzić czy jakaś zmienna jest ustawiona, czyli:

$bar = (isset($foo)) ? $foo : 666;
echo $bar; //666

Ostatnio na grupie php.internals toczy się dyskusja czy aby nie uczynić drugiego przypadku domyślnym tj:

$bar = $foo ? $foo: 666;
echo $bar; //666

Dzięki takiej zmianie jest krócej o te kilka uderzeń w klawiaturę by ustawić domyślna wartość jakiej zmiennej. Jest zarówno wielu zwolenników jak i przeciwników tej zmiany. Najważniejsze jednak jest, że Rasmus Lerdorf (BDFL php) uważa, że nie należy zmieniać już istniejącego zachowania ponieważ zrywa to wsteczną kompatybilność kodu. Wobec tego, zaproponowany został kolejny operator w postaci “??” mający to samo zastosowanie co poprzedni oprócz tego, że sprawdza tylko, czy jakaś wartość istnieje:

$value = $a[$key] ?? : 'Not set';

Niektórych też już poniosła fantazja i zaproponowali wersję:

$value = 'Not set' unless $a['key'];

Ciekaw jestem, czy często używacie operatora trójargumentowego, oraz jakie macie zdanie nt. ww. propozycji ?

We wczorajszym wpisie Dan Birken przedstawił propozycję dodania do biblioteki standardowej języka php funkcji str_slice($string, $start, $end = null);. Funkcja ta była by alternatywą dla substr dla tych osób, dla których argumenty przekazywane do substr wydają się niezbyt logiczne czy też niewygodne.

Przy okazji rozpoczęła się dyskusja o wprowadzeniu innych funkcji łańcuchów znaków, które często używane są w różnych projektach np. startsWith($search) czy endsWith($search).

Osobiście chętnie widziałbym te funkcje w php oraz gdzieś w dalekiej przyszłości zmianę string z typu prostego na obiekt, oczywiście w sposób transparentny dla starszego kodu.

Jakie jest Wasze zdanie ?

Jarrod Nettles w niedawnym wpisie na php.internals zgłosił propozycję wprowadzenia modyfikatorów widoczności dla klas. Propozycja postuluje, by podobnie jak w przypadku elementów klas (właściwości i metod), mieć możliwość ograniczenia widoczności klasy względem przestrzeni nazw. Jak miało by się to odbywać ? Przed deklaracją klasy można by umieścić jedno ze słów kluczowych – public, internal, lub private (albo public, protected, private):
read more »

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 ?