myGeeBlog

Jak wiadomo, przestrzenie nazw w PHP nie istnieją. Czasem ich brakuje, czasem nie robi różnicy… Ale jest dość prosty sposób na emulację tego braku.

Definiujemy sobie klasę o nazwie takiej, jak pożądana przestrzeń nazw, na przykład Path. W niej definiujemy sobie jakieś metody, np. join(), split() etc. Metody te definiujemy jako statyczne (static- nie chcemy musieć inicjalizować obiektu i korzystać z jego instancji, tylko chcemy mieć dostęp do samych metod. Klasę warto zdefiniować jako abstrakcyjną (abstract) - wtedy nie będziemy mieć możliwości utworzyć instancji jej obiektu. Efekt końcowy:

abstract class Path {
    public static function join()
    {
        // tresc funkcji
    }
    public static function split()
    {
        //tresc funkcji
    }
}

A korzystamy z niej:

Path::join('a', 'b');
Path::split('a/b/c');

Voila! :)

Jedynym problemem jest tutaj brak możliwości zaimportowania danej funkcji do ‘zwykłej’ przestrzeni nazw, czyli czegoś co w C++ robi dyrektywa using. Ale myślę, że nie po to chcemy stworzyć własną przestrzeń nazw, żeby z niej później wychodzić :)

Właśnie zaimplementowałem proste sprawdzanie typów w PHP5. Oczywiście, nie jest to C++, gdzie kontrola ta jest bardziej ścisła, ale myślę że w wielu wypadkach starczy. Jest to o tyle wygodne, że łatwiej nieco będzie wykrywać nieścisłości (zresztą, po to jest sprawdzanie typów).

Przykład kodu:

class Test
{
  protected $properties = array(
    'var1' => array('tralala', 'string'),
    'var2' => array(3, 'integer'),
    'var3' => array(array('tralala', 'bulcykcyk), 'array')
  );
  public function __set($key, $value)
  {
    if (!array_key_exists($key, $this->properties)) {
      throw new Exception(sprintf('"%s" property doesn\'t exists.', $key));
    }
    if (gettype($value) != $this->properties[$key][1]) {
      throw new Exception(sprintf('"%s" property must be an "%s" type, is "%s".',
          $key,
          $this->properties[$key][1],
          gettype($value)
      ));
    }
    $this->properties[$key][0] = $value;
  }
}

Najtrudniejszym elementem jest tutaj każdorazowe ustawianie właściwej konstrukcji zmiennej $properties, ponieważ ta tablica ma konkretny format:

$properties = array(
  'nazwa_zmiennej' => array('wartość', 'typ')
)

Jako ‘wartość‘ wstawiamy tam wartość właściwości (obojętnie, czy obiekt, int, string, tablicę czy coś innego), a jako ‘typ‘ - wartość zwracana przez funkcję getttype() wywołaną na przechowywanym obiekcie. Dla napisów będzie to wartość ‘string‘, dla liczb całkowitych: ‘integer‘, a dla obiektów: ‘object‘.

Ta kontrola typów jest o tyle uproszczona, że nie sprawdza, czy przechowywany obiekt jest instancją danej klasy (tej która ma być przechowywana), oraz czy tablica przechowuje żądany typ obiektów. O ile pierwsze czasem warto, i łatwo zrobić za pomocą is_a() czy też get_class(), o tyle drugie może być trudniejsze i wymagać funkcji dodatkowych (jeśli sprawdzanie ma być niezależne od ilości zagłębień tablicy).

Przykład użycia:

$a = new Test;
try {
  $a->var1 = 'asd';               //ok
  $a->var2 = 1;                   //ok
  $a->var3 = array(1, 2, 3);  //ok

  //$a->var1 = 1;              //exception!
  //$a->var2 = 'a';             //exception!
  //$a->var3 = 1;              //exception!
} catch (Exception $e) {
  echo $e->getMessage();
}

W moim wypadku najlepszym rozwiązaniem było utworzenie klasy ‘Test‘ jako abstrakcyjnej (’abstract‘) i tworzenie kolejnych klas jako dziedziczących z niej. Każde z dzieci musi oczywiście mieć swoją wersję tablicy ‘$properties‘.

Całkiem niezła biblioteka, podoba mi się jak na razie bardzo. Oczywiście, nie jest bezbłędna, ale takie rzeczy nie istnieją. Zgłosiłem bugreporta, zobaczymy czy i jak szybko zarezgują ;)

Generalnie wrażenia jak najbardziej pozytywne. Używa się całkiem przyjemnie, trochę ułatwiają pracę w stosunku do FT (heh, całkiem dużo…). Jeszcze nie mam biegłości w posługiwaniu się OPT-ami, ale dokumentacja jest pięknie opisana, zarówno po polsku jak i po angielsku, co całkiem dobrze mówi o twórcach :)

Wspomniany wcześniej błąd dotyczy instrukcji {foreach}, a konkretnie części {foreachelse}, która powinna wykonywać się gdy tablica przekazywana jako parametr jest pusta. Aplikacja po prostu się wysypuje, gdy dyrektywa {foreachelse} występuje w kodzie szablonu… No nic, bywa.

A teraz czas spać…

AKTUALIZACJA
Nie jest źle. Wczoraj bugreport, w tej chwili sprawdziłem FlySpraya, poprawka tymczasowa podana na tacy, i obietnica naprawy w najnowszym RC ;)

Prace nad Core osiągnęły pewien punkt zwrotny (w żadnym wypadku nie zostały przerwane, choć może cisza w repozytorium mogłaby to sugerować). Stwierdziliśmy z larkiem że trzeba przeorganizować i przepisać całe Core, aby móc je efektywnie rozwijać. Co też zaczeliśmy czynić. Przepisywanie zaczeliśmy od tego, od czego powinniśmy: od gadania :)

Postawiliśmy sobie prywatne wiki, gdzie spisujemy koncepcje i pomysły na to jak ma to działać i wyglądać. Zmieni się dosłownie wszystko - poza założeniami: ma być lekkie i szybkie. Będzie oczywiście miało dotychczasową funkcjonalność, będzie miało też obiecywaną dla wersji 0.5.0 funkcjonalność (galerie etc).

Zmieni się system szablonów (największe szanse w tej chwili ma system Open Power Template, w skrócie OPT). W tej kwestii jedno jest pewne: na pewno nie będzie to smarty, ponieważ obydwaj z larkiem posiadamy na smartowstręt :)

Zmienią się też wymagania systemowe (jak zresztą niketóre osoby, sprawdzające OPTy, mogły zauważyć) dla Core. Podstawą będzie: PHP 5.0 + PECLowe PDO lub też wersja PHP 5.1.x, gdzie PDO jest wbudowane.

Innym wymaganiem będzie wersja MySQL - od teraz wymagać będziemy wersji >= 4.1. Choć mam chrapkę na 5.0 ;) Widoki i triggery etc.. mniam… Niestety, o ile PHP 5.0.x jest coraz popularniejsze na komercyjnych serwerach, o tyle MySQL w tejże wersji niestety jest zbyt daleko w tyle. Szkoda.

Nie wiem na ile się uda, ale chciałbym móc puścić nowe Core na UTF-8 (to, jak dla mnie, jedna z ważniejszych przyczyn przejścia na MySQL 4.1.x, które intensywniej wspiera to kodowanie).

No i oczywiście korzystanie z PHP 5.x nie jest podyktowane tylko modą i PDO - które przecież też można mieć do wersji 4.x. Większym problemem jest tutaj duuuuża różnica w “obiektówce” tychże wersji PHP. W PHP 5.x model obiektowy został przepisany od nowa, zaimplementowany w zupełnie inny sposób, i chcielibyśmy skorzystać z jego dobrodziejstw. Co też zaczęliśmy już robić… :)

Jeszcze jednym powodem do przepisania całości jest to, że stara wersja, wraz ze starym systemem szablonów, kiepsko się nadaje do dodania obsługi pluginów do systemu. A w nowej będziemy starali sie to robić tak, żeby tą obsługę mozna było jak najszybciej dodać - umożliwi to niec łatwiejszy rozwój całości systemu.

Tak, właśnie takie coś sobie wymyśliłem jak siedziałem wczoraj w sądzie więzieniu. Do dyspozycji miałem:

• tradycyjny interfejs proceduralny mysql_*
• nowy w php5 interfejs mysqli_ (proceduralny)
• j.w. mysqli, ale obiektowo (OOP)
• uniwersalny interfejs (w wersjach PHP < 5.1.0 dostępny poprzez PECL) PDO

Niestety, o ile w wersji Windows-owej w pracy miałem wersję PHP 5.1.0beta3 (z wbudowanym PDO), o tyle w domu i na serwerze na którym stoi urzenia jest starsze, stabilne PHP 5.0.5, na którym wersja PECL-owa PDO nie chce mi działać. Ale też jakoś specjalnie nie walczyłem, żeby zadziałało. Nie chce mi się :)

Wyniki, wraz z testami online, można obejrzeć pod urzenia.net/wp-content/mysql_test/, a żródła plików: urzenia.net/wp-content/mysql_test/sources/.

Dostępne tam są, na dole, 3 linki do wyników jakie uzyskałem na 3 kompach, na których chciało mi się bawić w testy. Najbardziej mnie zszokowało porównanie z P4 2.4 GHZ i AMD64… heheh. Nie ma to jak 64 bity :) Do każdego z linków jest którki opis, na jakim sprzęcie były wykonywane testy, jaki soft etc.

Moje podsumowanie: nie ma znaczenia, którego z interfejsów się użyje. Różnice w wydajności między nimi są tak niewielkie, że imo pomijalne. Dla mnie najwygodniejszy chwilowo się wydaje MySQLi, choć zdecydowanie PDO zasługuje na uwagę. Niestety, na tą chwilę PHP5 (nie mówiąc o wszechdostępności PDO, związanej z nieistnieniem wersji stabilnej/końcowej PHP5.1 i nie działaniem - u mnie - wersji PECL-owej) nie jest jeszcze tak rozpowszechnione jak bym chciał, ze względu na niekompatybilność części softu, dostosowanej do możliwości i błędów ;) starszej wersji, tj. PHP4. Choć w wolnych chwilach prawdopodobnie zacznę przerabiać Core CMS na ‘międzymordzie’ (interfejs) MySQLi… :)

Niedługo też zostaną wznowione prace nad telefonami, które też może doczekają się przejścia na MySQLi, jako że następny hosting będzie u providera, który oferuje PHP5 :) Które to PHP coraz bardziej podbija moje serce (w stosunku do PHP4, nie w ogólności, gdzie python króluje… :) ).

Wszelkie uwagi i ew. zgłoszenia błędów procedury testowej proszę zostawiać w komentarzach - postaram się nimi zająć tak szybko jak się da :)