Podczas pisania pracy inżynierskiej natknąłem się na kilka ciekawych miejsc w kodzie, “produkujących” nieznane mi do tej pory błędy. Być może miałem świadomość ich istnienia, ale nie udało mi się jeszcze ich “popełnić”. W dzisiejszym wpisie chciałbym przedstawić Wam kolejny problem, tym razem dotyczący pewnych starszych mechanizmów języka PHP. Zapraszam do lektury.

Konstruktor klasy jest specjalną funkcją uruchamianą automatycznie podczas tworzenia nowej instancji klasy, jednokrotnie w trakcie życia danego obiektu (oczywiście możemy potem w jawny sposób wywołać go w kodzie, jednakże nie jest to polecana praktyka programistyczna). W języku PHP to stwierdzenie także jest prawdziwe, aczkolwiek w wielu miejscach interpreter udowadnia nam, że z powodzeniem możemy potraktować konstruktor jak zwykłą funkcję.

O ile przerwa w tworzeniu tradycyjnych wpisów na niniejszym blogu została pomyślnie przerwana, o tyle z przywróceniem serii Linkdump był już pewien problem. Na szczęście dostałem z zewnątrz odpowiednią ilość pozytywnej energii, stąd przełamanie bariery lenistwa okazało się o wiele łatwiejsze. ;] Tak jak w pierwszym wpisie z tej serii temat powraca niczym bumerang, stąd “znowu” zapraszam do zapoznania się ze znalezionymi przeze mnie perełkami na temat JavaScriptu.

W kwestii obsługi sesji i rodzaju zapisywanych w niej danych programiści PHP dzielą się na dwa skrajne fronty: tych, którzy preferują zapis wyłącznie typów prostych i tych, którzy nie widzą problemu w trzymaniu w niej całych obiektów. Ja stoję murem za typami prostymi, ponieważ wydaje mi się bardziej optymalne zapisywanie tylko niezbędnych informacji, na podstawie których ewentualne obiekty można odtworzyć, pozwala to też na zmniejszenie obciążenia serwera, bo odczytanie sesji wymaga deserializacji [odserializowania? deserializowania? kolejne "ciężkopolskie" słowo...] i parsowania o wiele mniejszego pliku. Jakkolwiek byśmy jednak do tego nie podchodzili, dzisiejszy wpis także może być argumentem in plus dla zapisywania wyłącznie zmiennych typów prostych, ponieważ jak mówi stare programistyczne porzekadło: "Serializujesz obiekty [do sesji]? No to masz problem!". ;]

Dzisiaj czytałem nieco o klasach zaprzyjaźnionych w języku C++ [ang. friend classes] i podczas lektury jednego z artykułów przypomniało mi się znane z podstawówki powiedzenie “co je twoje, to je moje, a co moje, to nie rusz”. Przez chwilę patrzyłem na przykładowy kod i nagle wpadł mi do głowy pewien pomysł. Wymyśliłem implementację tego powiedzenia w C++. ;] Oznaczenie klasy jako zaprzyjaźnionej z inną oznacza m. in. to, że wszystkie atrybuty tej pierwszej, niezależnie od klasyfikatora dostępu [public, protected, private] stają się dostępne dla drugiej bez żadnych ograniczeń. Pierwsza klasa “przekazuje” wszystkie informacje o sobie tej drugiej tak, jakby kwalifikatorem dostępu dla wszystkich jej elementów [atrybutów i metod] było słowo kluczowe public. Analogia jest, przynajmniej dla mnie, bardzo wyraźna. ;]