The Explorer

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

Wczoraj Stas Malyshev ponownie podniósł kwestię rozwoju PHP 5.4. Zaproponował następujący plan:

• od obecnej chwili do 18 maja mają być zgłaszane propozycje cech, które są pożądane w tej wersji
• 18 maja – początek dyskusji i głosowania nad cechami, które się znajdą w wersji finalnej
• 15 czerwiec – wersja alfa, wydzielenie brancha 5.4 z trunka, koniec z dodawaniem nowych ficzerów, tylko poprawki błędów i rozwój zaakceptowanych cech
• 20 lipiec – beta tylko poprawki błędów
• 24 sierpień – Release Candidate 1 i kolejne RC co 2 tygodnie
• Październik / Listopad – wersja finalna

Plan jaki zaproponował Stas wydaje się dość realistyczny i zyskał już poparcie Rasmusa Lerdorfa (BDFL PHP). Wszystkich ciekawych, co znajdzie się w PHP 5.4 zachęcam do czytania dokumentu „TODO„.

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 »