🚀 go-pugleaf

W dniu 18.01.2018 o 13:37, Roman Tyczka pisze:
> 
> Może rozruszam tę grupę ;-)
> 
> Mam pytanie o dobre praktyki w PHP. Chodzi mi szczególnie o kardynalne
> błędy, które wpływają na spadek wydajności działania skryptu. Na codzień
> programuję w Delphi i takich rzeczy jest sporo, które nawet nie całkiem
> początkujący ignorują, a które potrafią dramatycznie rzutować na wydajność.
> Przykładem jest przekazywanie stringów czy tablic przez wartość a nie
> referencję, co skutkuje alokacją i kopiowaniem pamięci a to proces
> czasochłonny.
> 
> Czy moglibyście wypunktować kilka takich bad practicies dla PHP?
> 

- includowanie kodu, który nigdy (podczas tego wywołania) się nie wykona
- przechowywanie kodu poza plikami php i wykonywanie przez eval()
- brak zwalniania pamięci po pracy z dużymi danymi
- przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
- brak keszowania fragmentów strony wynikowej mp.
menu - zmieni się wtedy gdy administrator je zmieni raz na ruski rok. 
Ale strona (a zatem menu) zostanie pobrana wielokrotnie. Gdyby HTML 
odpowiedzialny za menu został wygenerowany tuż po zmianie w CMSie to 
każde wywołanie strony oszczędzi czas procka pobierając dane z kesza a 
nie wywołując procedury generowania menu.

- stosowanie nieodpowiednich systemów przechowywania danych - obrazki w 
bazie danych, dane w CSV w pliku.

-- 
Pozdrawiam
Lemat

fajne to pytanie
to pytanie z cyklu "jak lepiej zoptymalizować na etapie pisania programu 
  zamiast zwalić to na kompilator" - wiele łbów na politechnice na tym 
poległo...

Dobre praktyki. (1 -5) załatwiają frameworki 

1. Projekt opieraj o klasy i obiekty.
2. Wykorzystuj metody magiczne __autoload (automatyczne ładowanie klas podczas ich wywołania)
3. Wykorzystuj zmienne statyczne w stałych plikach (ograniczysz kopiowanie zmiennych).
4. Poznaj różnicę między przekazaniem argumentu do funkcji a argumentu do metody (klasa w funkcji) 
5. Ograniczaj używanie zmiennych globalnych do minimum. 
6. W metodach buduj gettery i settery a zmienne dawaj do private.


Poznaj PSR-1/2/3 -> to standard (hardcorowcy idą do 7 :)

On Sun, 21 Jan 2018 05:03:14 -0800 (PST), Rafal Podsiadly wrote:

> 2. Wykorzystuj metody magiczne __autoload (automatyczne ładowanie klas podczas ich wywołania)

Właśnie trafiłem na notkę w opisie:


Warning

This feature has been DEPRECATED as of PHP 7.2.0. Relying on this feature
is highly discouraged.


-- 
pozdrawiam
Roman Tyczka

Dnia Sun, 21 Jan 2018 05:03:14 -0800 (PST), Rafal Podsiadly napisał(a):

> 3. Wykorzystuj zmienne statyczne w stałych plikach (ograniczysz kopiowanie zmiennych).

Możesz rozwinąć?

> 4. Poznaj różnicę między przekazaniem argumentu do funkcji a argumentu do metody (klasa w funkcji) 

Jw. W internals są jakieś konkretne różnice, które trzeba mieć na uwadze?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Zmienne statyczne singelton cos ci mowi?

Poczytaj tez o przekazywaniu zmiennej do metody w klasie a przekazywaniu zmiennej do funkcji. O klasach statycznych. Różnicach w wykorzystaniu or and w warunku if. W jaki sposob robic dobre warunki. Czyli mapa wynikow zanim zaczniemy pisac zlozony if.

O tym ze lepiej na poczatku funkcij sprawdzic warunek konieczny 5 linijek i zrzucic blad niz opakowac 100 linijek kogu w if. O tym jak dzialaja if a funkcie. I czy warto.

On 2018-01-24, Rafal Podsiadly <spinacz24@gmail.com> wrote:
> Zmienne statyczne singelton cos ci mowi?

Singleton został uznany za anti-pattern gdzieś w okolicach
popularyzacji dependency-injection pattern.

Z wielu powodów.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On Wed, 24 Jan 2018 08:16:15 -0800 (PST), Rafal Podsiadly wrote:

> Poczytaj tez o przekazywaniu zmiennej do metody w klasie a przekazywaniu
> zmiennej do funkcji. O klasach statycznych. Różnicach w wykorzystaniu or
> and w warunku if. W jaki sposob robic dobre warunki. Czyli mapa wynikow
> zanim zaczniemy pisac zlozony if. 
> 
> O tym ze lepiej na poczatku funkcij sprawdzic warunek konieczny 5
> linijek i zrzucic blad niz opakowac 100 linijek kogu w if. O tym jak
> dzialaja if a funkcie. I czy warto.

Zamiast tony if'ów stosuje się polimorfizm. Odkąd PHP jest obiektowe chyba
to jest lepsza droga?

-- 
pozdrawiam
Roman Tyczka

To prawda singeltona trzeba umiec uzywac. Np. W bazach danych do utrzymywania polaczen.

Nie zawsze da sie zastosowac polimorfizm. Na przyklad gdy dane ida postem i kolejne pola zmieniaja logike cos dodajac lub konfigurujac. 

W sumie nie wiem czy spotkalem sie z kodem ktory nie mial by wadliwych if.

Ale polimorfizm jest zdecydowanie lepszym podejsciem w miejscu gdzie mozna go zastosowac.

W dniu 18-01-2018 o 18:30, Lemat pisze:

> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE

Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto aby nie 
robić czegoś takiego jak:

$sql="SELECT ... JOIN / WHERE";
$bazaDanych->execute($sql);

Jeśli tak, to w jaki sposób budujesz zapytania do bazy typu PostgreSQL 
(moja ulubiona) lub podobna, wykonujesz je i zwracasz do PHP wyniki? 
Zakładam w pytaniu, że projekt jest dużo bardziej złożony niż zadanie 5 
na krzyż niemodyfikowalnych zapytań SQL do bazy.

-- 
Pozdrawiam,
Marek

W dniu 21-01-2018 o 14:03, Rafal Podsiadly pisze:

> 2. Wykorzystuj metody magiczne __autoload (automatyczne ładowanie klas podczas ich wywołania)

Raczej "unikaj"



-- 
Pozdrawiam,
Marek

W dniu 25.01.2018 o 20:31, Marek S pisze:
> W dniu 18-01-2018 o 18:30, Lemat pisze:
> 
>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
> 
> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto 

nie.
Wręcz przeciwnie.

-- 
Pozdrawiam
Lemat

W dniu 25-01-2018 o 06:30, Rafal Podsiadly pisze:

> To prawda singeltona trzeba umiec uzywac. Np. W bazach danych do utrzymywania polaczen.

Właśnie to samo chciałem od siebie napisać.
Dodam jedynie, że w swoich projektach nieco to obszedłem (może to złe 
wyrażenie - opakowałem ładniej) tworząc klasę narzędziową nadrzędną do 
wszystkich pozostałych. W niej m.in. nawiązuję połączenie z bazą i 
monitoruję poprawność zamykania handlerów przez wszystkie pozostałe 
klasy itp.

-- 
Pozdrawiam,
Marek

W dniu 25-01-2018 o 20:44, Lemat pisze:
> W dniu 25.01.2018 o 20:31, Marek S pisze:
>> W dniu 18-01-2018 o 18:30, Lemat pisze:
>>
>>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
>>
>> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto 
> 
> nie.
> Wręcz przeciwnie.

Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? 
Jakiś przykład?

-- 
Pozdrawiam,
Marek

On 2018-01-25, Rafal Podsiadly <spinacz24@gmail.com> wrote:

> To prawda singeltona trzeba umiec uzywac. Np. W bazach danych do utrzymywania polaczen.

https://stackoverflow.com/questions/12755539/why-is-singleton-considered-an-anti-pattern
https://www.michaelsafyan.com/tech/design/patterns/singleton

Bazy danych to najczęściej factory.
A singletony to pain-in-the-ass podczas pisania testów.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On Thu, 25 Jan 2018 20:48:16 +0100, Marek S wrote:

>>>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
>>>
>>> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto 
>> 
>> nie.
>> Wręcz przeciwnie.
> 
> Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? 
> Jakiś przykład?


Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
pomysł, ale pewnie są i tacy patenciarze ;-)


-- 
pozdrawiam
Roman Tyczka

W dniu 25-01-2018 o 21:22, Roman Tyczka pisze:

> 
> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
> pomysł, ale pewnie są i tacy patenciarze ;-)

eeee... jakoś nie dowierzam, że o to mogłoby chodzić Lematowi. Brzmi to 
trochę za bardzo przekombinowanie :-D

-- 
Pozdrawiam,
Marek

On 2018-01-25, Roman Tyczka <noemail@because.no> wrote:

[...]

> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
> pomysł, ale pewnie są i tacy patenciarze ;-)

Czyli każdy ORM z lazy-loadingiem?

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 25-01-2018 o 21:10, Wojciech Bancer pisze:

> https://stackoverflow.com/questions/12755539/why-is-singleton-considered-an-anti-pattern
> https://www.michaelsafyan.com/tech/design/patterns/singleton
> 
> Bazy danych to najczęściej factory.
> A singletony to pain-in-the-ass podczas pisania testów.
> 

Cytat z linku jaki przesłałeś zachęca do singletonów przy bazach :-)

If you find that you want to use a singleton, you may want to consider 
your design, but there are times where it is useful.

For example, once I had to write an application that could have at most 
one database connection, to process thousands of requests. So, a 
singleton makes sense since I am resource constrained to having only one 
instance.

-- 
Pozdrawiam,
Marek

W dniu 2018-01-25 o 20:48, Marek S pisze:
> W dniu 25-01-2018 o 20:44, Lemat pisze:
>> W dniu 25.01.2018 o 20:31, Marek S pisze:
>>> W dniu 18-01-2018 o 18:30, Lemat pisze:
>>>
>>>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
>>>
>>> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto 
>>
>> nie.
>> Wręcz przeciwnie.
> 
> Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? 
> Jakiś przykład?
> 
Wszystko zależy. Czasem nie dasz rady. To wygląda tak, dostałem zlecenie na 
zrobienie ornungu w bazie. Miałem założyć triggery (służące utrzymaniu 
porządku między tabelami). Zrobiłem na developerskiej bazie, przyszedł czas 
na wdrożenie, wszyscy dostali papiery z opisem zależności. Nie minęło 2h i 
gość przyłazi "Do bazy nic nie mogę dopisać" ???!!!!
Z innej mańki, baza ma swoją logikę, dane są rozrzucane i zapisywane w 
różnych tabelach. Nie próbuj tego łamać na siłę, powinieneś dostać 
procedury/funkcje, które realizują logikę bazy.
Żeby załapać co wymyślili w Insert (MS SQL) zeszło mi z miesiąc, choć w 
bazie na żywca nie odważyłem się grzebać :)

-- 
Artur

On 2018-01-25, Marek S <precz@spamowi.com> wrote:

[...]

> For example, once I had to write an application that could have at most 
> one database connection, to process thousands of requests. So, a 
> singleton makes sense since I am resource constrained to having only one 
> instance.

To doczytaj komentarze do tego :)


-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 25.01.2018 o 23:55, Marek S pisze:
> W dniu 25-01-2018 o 21:22, Roman Tyczka pisze:
> 
>>
>> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
>> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
>> pomysł, ale pewnie są i tacy patenciarze ;-)
> 
> eeee... jakoś nie dowierzam, że o to mogłoby chodzić Lematowi. Brzmi to 
> trochę za bardzo przekombinowanie :-D
> 

niedowiarek...
A ja znam osobiście takich programistów, którzy się na tym sparzyli.

-- 
Pozdrawiam
Lemat

W dniu 26-01-2018 o 05:48, Lemat pisze:
> 
> niedowiarek...
> A ja znam osobiście takich programistów, którzy się na tym sparzyli.

To jestem pod wrażeniem :-)

-- 
Pozdrawiam,
Marek

W dniu 26-01-2018 o 00:26, Wojciech Bancer pisze:

> 
> To doczytaj komentarze do tego :)

Oj pewnie! :-) A Ty doczytaj kolejne :-D

W ten sposób cały dzień gadać można: ktoś będzie ciągnął w jedną stronę, 
ktoś inny w drugą. Tymczasem temat jest prosty w/g mnie. Wielokrotne 
inicjowanie połączenia do bazy danych jest katastrofą dla wydajności 
softu. Zrobienie tego raz na początku i posprzątanie na końcu jest 
jedyną słuszną (moim prywatnym zdaniem) drogą. Aby "coś" móc zrobić z 
danym obiektem na początku i na końcu to musi on cały czas istnieć 
miedzy początkiem a końcem. Prawda? Wtedy zbliżamy się do singletonów 
lub pokrewnych rozwiązań.

Zwróć uwagę, że pojęcie sesji w PHP/ASP/czymkolwiek też jest takim 
niby-singletonem a jakoś nikt nie rozpacza nad jej istnieniem.

-- 
Pozdrawiam,
Marek

On Fri, 26 Jan 2018 00:02:00 +0100, Wojciech Bancer wrote:

>> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
>> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
>> pomysł, ale pewnie są i tacy patenciarze ;-)
> 
> Czyli każdy ORM z lazy-loadingiem?

Jeśli znasz ORMa, który ściąga całą tabelę, żeby wyjąć z niej jeden wiersz
to zastrzel jego autora ;-)
A lazy loading... domyślam się o co Ci może chodzić, że ORM żeby zrobić
powiązanie między obiektami musi wczytać kilka tabel, ...ale dobry
framework ORM potrafi generować JOINy na poziomie zapytań i nie musi
ściągać do tego całych tabel na klienta. Nie wiem jakie ORMy są w świecie
php, bo zasadniczo nie przepadam za ORMami, ale w Javie, .NET czy w Delphi
ORMy potrafią inteligentnie tworzyć zapytania i wykorzystywać możliwości
SQLa.

-- 
pozdrawiam
Roman Tyczka

On 2018-01-26, Marek S <precz@spamowi.com> wrote:

[...]

>> To doczytaj komentarze do tego :)
>
> Oj pewnie! :-) A Ty doczytaj kolejne :-D
>
> W ten sposób cały dzień gadać można: ktoś będzie ciągnął w jedną stronę, 
> ktoś inny w drugą. Tymczasem temat jest prosty w/g mnie. Wielokrotne 
> inicjowanie połączenia do bazy danych jest katastrofą dla wydajności 
> softu.

Nikt nie pisał o wielokrotnym inicjowaniu połączeń.
Doczytaj sobie o wzorcach dependency injection.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On 2018-01-26, Roman Tyczka <noemail@because.no> wrote:
> On Fri, 26 Jan 2018 00:02:00 +0100, Wojciech Bancer wrote:
>
>>> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
>>> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
>>> pomysł, ale pewnie są i tacy patenciarze ;-)
>> 
>> Czyli każdy ORM z lazy-loadingiem?
>
> Jeśli znasz ORMa, który ściąga całą tabelę, żeby wyjąć z niej jeden wiersz
> to zastrzel jego autora ;-)

Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak 
sobie już sobie iterujesz po obiektach będących odwołaniami do innych 
tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego 
joina.

Na pewno Propel i Doctrine postępują wg metody jak wyżej.
Widziałeś ORMa działającego inaczej?

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 27-01-2018 o 13:05, Wojciech Bancer pisze:

> 
> Nikt nie pisał o wielokrotnym inicjowaniu połączeń.
> Doczytaj sobie o wzorcach dependency injection.

Ale to właśnie jest jedną z implementacji takich singletonów - tu 
zwanych pluginami. Różnica leksykalna.

Cytat z Wiki:
"Polega na przekazywaniu gotowych, utworzonych instancji obiektów 
udostępniających swoje metody i właściwości obiektom, które z nich 
korzystają (np. jako parametry konstruktora)"

Te "gotowe instancje" to są nic innego jako singletony wygenerowane 
przez ich fabrykę. Przez fabrykę otrzymujesz globalny dostęp do 
stworzonych obiektów - a taka jest właśnie definicja singletonów.

-- 
Pozdrawiam,
Marek

On 2018-01-27, Marek S <precz@spamowi.com> wrote:


>> Nikt nie pisał o wielokrotnym inicjowaniu połączeń.
>> Doczytaj sobie o wzorcach dependency injection.
>
> Ale to właśnie jest jedną z implementacji takich singletonów - tu 
> zwanych pluginami. Różnica leksykalna.

Nie, różnica nie jest leksykalna.

Różnica jest taka, że zależności dostarcza odpowiedni 
manager, i kod który wykorzystuje te zależności nie ma 
odpowiedzialności w której musi sobie daną zależność 
sam "pobrać" - co jest najczęstszą wadą w projektach
opeartych o prosty singleton.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 27-01-2018 o 14:49, Wojciech Bancer pisze:

> Różnica jest taka, że zależności dostarcza odpowiedni
> manager, i kod który wykorzystuje te zależności nie ma
> odpowiedzialności w której musi sobie daną zależność
> sam "pobrać" - co jest najczęstszą wadą w projektach
> opeartych o prosty singleton.

Ok, to może inaczej - pójdźmy piętro wyżej. Czym jest zatem ten manager? 
Czyż nie singletonem?

To co chcę powiedzieć, to to, że zawsze na szczycie aplikacji jest jakiś 
obiekt "guru". Czy nazwiemy go tak czy siak, to i tak będzie sobie 
istniał jako byt zainicjowany na początku, z którego istnienia czerpią 
korzyści inni. Pojęcia leksykalne są czasem rozmyte.

-- 
Pozdrawiam,
Marek

On 2018-01-27, Marek S <precz@spamowi.com> wrote:

[...]

>> Różnica jest taka, że zależności dostarcza odpowiedni
>> manager, i kod który wykorzystuje te zależności nie ma
>> odpowiedzialności w której musi sobie daną zależność
>> sam "pobrać" - co jest najczęstszą wadą w projektach
>> opeartych o prosty singleton.
>
> Ok, to może inaczej - pójdźmy piętro wyżej. Czym jest zatem ten manager? 
> Czyż nie singletonem?

A jest powód by był singletonem?

> To co chcę powiedzieć, to to, że zawsze na szczycie aplikacji jest jakiś 
> obiekt "guru".

Ale to jest powiedzmy kernel aplikacji, który postępuje wg pewnego ustalonego
sposobu. Gdzie tu widzisz potrzebę na singletona?

> Czy nazwiemy go tak czy siak, to i tak będzie sobie 
> istniał jako byt zainicjowany na początku, z którego istnienia czerpią 
> korzyści inni. Pojęcia leksykalne są czasem rozmyte.

Ja widzę różnicę:

<?php

class PobieramZBazy() {
    ___construct($cn) { $this->cn = $cn; }
    public getCostam() {
        return $this->cn->query(...);
    }
}

vs

class PobieramZBazy() {
    public getCostam() {
        $cn = JakisGlobalnyCusik::pobierzPolaczenie();
        return $cn->query(...);
    }
}

Tylko tyle i "aż" tyle, że to pierwsze się łatwiej testuje,
bo nie trzeba kombinować ze sztucznym mockowaniem statycznych
metod, tylko można sobie wstrzyknoć co potrzeba w kontrolerze.

Czyste i eleganckie. Oczywiście jak masz dobre zarządzanie
zależnościami, np. jak w Symfony2+.

A w 90% przypadków jakie widziałem, to Wielbiciele Singletonów
potrafili pisać masywną ilość metod statycznych, bo skoro "to
tak fajnie działa w przypadku singletona, to piszmy sobie 
skróty" :P

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 27-01-2018 o 20:35, Wojciech Bancer pisze:

> 
> A jest powód by był singletonem?

Poniżej

> 
>> To co chcę powiedzieć, to to, że zawsze na szczycie aplikacji jest jakiś
>> obiekt "guru".
> 
> Ale to jest powiedzmy kernel aplikacji, który postępuje wg pewnego ustalonego
> sposobu. Gdzie tu widzisz potrzebę na singletona?

Właśnie, trafiłeś w sedno w sformułowaniu "ale to jest _powiedzmy_ 
kernel". Słowo klucz to "powiedzmy". Mógłbym powiedzieć "zgoda" albo 
mógłbym powiedzieć "to jest właśnie singleton" i na jedno by wyszło. 
Kernel jest singletonem.

Zobrazuję to na podstawie Twojego przykładu. Oczywiście należy tak 
postępować jak poniżej:

 > class PobieramZBazy() {
 >      ___construct($cn) { $this->cn = $cn; }
 >      public getCostam() {
 >          return $this->cn->query(...);
 >      }
 > }

...ale właśnie teraz wpadasz w pułapkę tego, o czym cały czas piszę. 
Skąd masz połączenie do bazy $cn? Gdzieś ono musiało być zainicjowane i 
przechowywane przez całą długość życia aplikacji. Prawda? Zrobi to nasz 
"kernel" i udostępni innym obiektom handler do raz ustanowionego połączenia.

Teraz popatrz jak powstaje z kernela singleton:

class kernelZwanySingletonem() {
	private $connection;
	
	public function getConnection() {
		return $connection;
	}
	
	__construct() {
		//tu kupa kodu plus inicjacja bazy
		$this->$connection=...
	  }

	__destruct() {
		//tu kupa kodu
		zamknijPołączenieZBazaIZapiszLogi($connection);
	}
}

$singleton=new kernelZwanySingletonem();
$singleton->runApplication();

...aplikacja sobie działa i potrzebuje w pewnym momencie dostępu do 
bazy. I co wtedy robi? A no to co napisałeś.

$cosTam=new PobieramZBazy($singleton->getConnection());
$wyniki=$cosTam->getCosTam();

... aplikacja dalej pracuje i znów jakiś inny jej moduł potrzebuje 
grzebania w bazie więc:

$cosTam2=new PobieramZBazyCosInnego($singleton->getConnection());
$wyniki=$cosTam2->getCosTam();

Gdy aplikacja kończy żywot, to niejawnie wołany jest destruktor kernela 
zwanego singletonem. Baza pięknie się zamyka, ba, można nawet sprawdzić 
w tym miejscu czy moduły pozamykały prawidłowo swoje recordsety i jeśli 
nie, to w logach zapisać alerty.

Ten nasz "kernel" czy klasa "guru" to właśnie nasz singleton. Z jego 
egzystencji wszelkie pozostałe funkcjonalności czerpią soki.

I jeszcze jedno: singleton to nie jest masywna ilość statycznych metod. 
Singleton nie musi mieć żadnej statycznej. Cytat z Wiki:

"Singleton – kreacyjny wzorzec projektowy, którego celem jest 
ograniczenie możliwości tworzenia obiektów danej klasy do jednej 
instancji oraz zapewnienie globalnego dostępu do stworzonego obiektu."

Nasz kernel wypełnia wszelkie przesłanki bycia singletonem i jest on 
jedynym singletonem w całej aplikacji tej mini aplikacji. Nawet ciężko 
mi sobie wyobrazić aplikację, nie ma żadnego nadrzędnego obiektu, który 
siłą rzeczy staje się singletonem. No chyba, że programujemy liniowo w 
jakimś Basicu itp. Ważne jest aby tylko jeden tego typu obiekt 
występował pełniąc rolę np. managera pluginów (z pluginem bazy danych 
włącznie) - jak to wcześniej nazwaliśmy.

-- 
Pozdrawiam,
Marek

Dnia Wed, 24 Jan 2018 20:29:38 +0100, Roman Tyczka napisał(a):

> Zamiast tony if'ów stosuje się polimorfizm. Odkąd PHP jest obiektowe chyba
> to jest lepsza droga?

A gdzie masz w PHP polimorfizm?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Wed, 24 Jan 2018 08:16:15 -0800 (PST), Rafal Podsiadly napisał(a):

> Poczytaj tez o przekazywaniu zmiennej do metody w klasie a przekazywaniu
> zmiennej do funkcji. O klasach statycznych. Różnicach w wykorzystaniu or
> and w warunku if. W jaki sposob robic dobre warunki. Czyli mapa wynikow
> zanim zaczniemy pisac zlozony if.

Nie musisz mi tłumaczyć podstawowych pojęć. Ja się pytam, czy znasz jakieś
różnice w kontekście wydajności przy obsłudze parametrów w funkcji, a w
metodzie.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Sat, 27 Jan 2018 13:40:24 +0100, Marek S napisał(a):

>> Nikt nie pisał o wielokrotnym inicjowaniu połączeń.
>> Doczytaj sobie o wzorcach dependency injection.
> 
> Ale to właśnie jest jedną z implementacji takich singletonów - tu 
> zwanych pluginami. Różnica leksykalna.

Nie. DI to kontrolowane przekazywanie obiektu, zamiast magicznego
pojawiania się tego obiektu gdzieś wewnątrz kodu.

Wojtek próbuje Ci wytłumaczyć, że to ma krytyczne znaczenie podczas testów,
gdzie często nie masz dostępu do połączenia z bazą. Albo z takiego
połączenia byłoby więcej problemów, niż pożytku.

Owszem, jeden singleton jeszcze da się jakoś obejść. Ale ten wzorzec często
kusi.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 2018-01-27, Marek S <precz@spamowi.com> wrote:

[...]

>>> To co chcę powiedzieć, to to, że zawsze na szczycie aplikacji jest jakiś
>>> obiekt "guru".
>> 
>> Ale to jest powiedzmy kernel aplikacji, który postępuje wg pewnego ustalonego
>> sposobu. Gdzie tu widzisz potrzebę na singletona?
>
> Właśnie, trafiłeś w sedno w sformułowaniu "ale to jest _powiedzmy_ 
> kernel". Słowo klucz to "powiedzmy". Mógłbym powiedzieć "zgoda" albo 
> mógłbym powiedzieć "to jest właśnie singleton" i na jedno by wyszło. 
> Kernel jest singletonem.

A skąd założenie że jest singletonem?

> ...ale właśnie teraz wpadasz w pułapkę tego, o czym cały czas piszę. 
> Skąd masz połączenie do bazy $cn? Gdzieś ono musiało być zainicjowane i 
> przechowywane przez całą długość życia aplikacji. Prawda? Zrobi to nasz 
> "kernel" i udostępni innym obiektom handler do raz ustanowionego połączenia.

I ponownie, skąd założenie że jest singletonem?

> Teraz popatrz jak powstaje z kernela singleton:
>
> class kernelZwanySingletonem() {
> 	private $connection;
> 	
> 	public function getConnection() {
> 		return $connection;
> 	}
> 	
> 	__construct() {
> 		//tu kupa kodu plus inicjacja bazy
> 		$this->$connection=...
> 	  }
>
> 	__destruct() {
> 		//tu kupa kodu
> 		zamknijPołączenieZBazaIZapiszLogi($connection);
> 	}
> }
>
> $singleton=new kernelZwanySingletonem();
> $singleton->runApplication();

Gdzie tu widzisz wzorzec singletona?
Rozumiesz czym jest ten wzorzec?

> ...aplikacja sobie działa i potrzebuje w pewnym momencie dostępu do 
> bazy. I co wtedy robi? A no to co napisałeś.

Nie. Aplikacja w konfiguracji trzyma opisy zależności dla poszczególnych
serwisów i udostępnia konterner z tymi serwisami, już zainicjalizowanymi
(lub inicjowanymi w momencie pierwszego załadowania jak dana zależność
wspiera lazy loading). Jednak w tym momencie nie potrzebujemy w ogóle
zmiennych statycznych, a ponieważ inicjalizuje i kontroluje wszystko 
manager, to mamy kontrolę nad ilością tworzonych obiektów bez uciekania
się do sztuczek z wzorcem singletona.

> I jeszcze jedno: singleton to nie jest masywna ilość statycznych metod. 
> Singleton nie musi mieć żadnej statycznej. Cytat z Wiki:
>
> "Singleton – kreacyjny wzorzec projektowy, którego celem jest 
> ograniczenie możliwości tworzenia obiektów danej klasy do jednej 
> instancji oraz zapewnienie globalnego dostępu do stworzonego obiektu."

Nie.
1. Nie ma potrzeby zapewniania globalnego dostępu
2. Możesz tworzyć więcej obiektów, po prostu nie jest to potrzebne.

Wzorzec singletona zakłąda w praktyce istnienie konstruktora
prywatnego i metody statycznej go jego tworzenia. Wtedy jesteś
w stanie zapewnić oba powyższe punkty.

> Nasz kernel wypełnia wszelkie przesłanki bycia singletonem i jest on 
> jedynym singletonem w całej aplikacji tej mini aplikacji.

Nie wypełnia.

> Nawet ciężko mi sobie wyobrazić aplikację, nie ma żadnego nadrzędnego 
> obiektu, który siłą rzeczy staje się singletonem.

No to mamy niezgodę, bo ja nie uznaję dowolnego pojedynczego obiektu
za singletona tylko dlatego że jest jeden :P

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

Dnia Sat, 27 Jan 2018 13:09:23 +0100, Wojciech Bancer napisał(a):

> Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak 
> sobie już sobie iterujesz po obiektach będących odwołaniami do innych 
> tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego 
> joina.
> 
> Na pewno Propel i Doctrine postępują wg metody jak wyżej.
> Widziałeś ORMa działającego inaczej?

Eloquent z Laravela może na wejściu dostać "hinta" with(...) z czym dane
będą w przyszłości wiązane. Wówczas potrafi zbudować takie zapytanie, które
wrzuci w cache od razu więcej danych i przyszłe zapytania nawet nie dotkną
bazy.

Potrafi też przy iteracji grupować identyfikatory i wysłać do bazy jedno
"IN (...)".

Całkiem nieźle to działa.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 2018-01-27, Borys Pogoreło <borys@pl.edu.leszno> wrote:
> Dnia Sat, 27 Jan 2018 13:09:23 +0100, Wojciech Bancer napisał(a):
>
>> Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak 
>> sobie już sobie iterujesz po obiektach będących odwołaniami do innych 
>> tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego 
>> joina.
>> 
>> Na pewno Propel i Doctrine postępują wg metody jak wyżej.
>> Widziałeś ORMa działającego inaczej?
>
> Eloquent z Laravela może na wejściu dostać "hinta" with(...) z czym dane
> będą w przyszłości wiązane. Wówczas potrafi zbudować takie zapytanie, które
> wrzuci w cache od razu więcej danych i przyszłe zapytania nawet nie dotkną
> bazy.

To mi przypomina rozwiązania z Propela 1.x :)
Faktycznie było to fajnie, chociaż propel miał swoje ogromne minusy
(metody statyczne do obsługi zapytań baz danych).

Laravel też chyba na statykach jedzie, z tego co pamiętam?

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 27-01-2018 o 22:49, Borys Pogoreło pisze:

> Wojtek próbuje Ci wytłumaczyć, że to ma krytyczne znaczenie podczas
> testów, gdzie często nie masz dostępu do połączenia z bazą. Albo z
> takiego połączenia byłoby więcej problemów, niż pożytku.
> 
> Owszem, jeden singleton jeszcze da się jakoś obejść. Ale ten wzorzec
> często kusi.

Ja to wszystko doskonale rozumiem. Chodzi mi o zupełnie coś innego.
Przeczytaj moją ostatnią wypowiedź udzieloną Wojtkowi. Wyjaśnię o jaki 
tok rozumowania mi chodzi. Za pomocą singletonów niektórzy piszą całą 
aplikację. Tego nawet nie biorę pod uwagę.

Chodzi mi o to, że nie da się w zasadzie tak napisać aplikacji aby nie 
miała jednego, nadrzędnego singletona. Cała aplikacja bazuje na modelu 
DI ale jej "kernel" _zawsze_ musi być zainicjowany globalnie. A jeśli 
jest zainicjowany globalnie to staje się singletonem.

Pojęcie singletona dotyczy tylko nadrzędnego obiektu dla wszystkich. 
Cała reszta może nie spełniać definicji singletonów.

Może to abstrakcyjnie zilustruję. Niech oprogramowanie DI przypomina 
książkę. Są w niej rozdziały, w rozdziałach zdania, w zdaniach wyrazy. 
Widać hierarchię. Każdy z wyrazów, rozdziałów ma dostęp do książki, 
której część stanowi. Książka pozwala na współzależność rozdziałów.

A od czego zależy sama książka? Od niczego! Stanowi samoistny byt. 
Singleton! :-) Uruchamiamy na serwerze 10 aplikacji lub 10 instancji tej 
samej aplikacji - mamy 10 singletonów.

Czy robię jakiś błąd myślowy?

-- 
Pozdrawiam,
Marek

Dnia Sat, 27 Jan 2018 23:07:29 +0100, Wojciech Bancer napisał(a):

> To mi przypomina rozwiązania z Propela 1.x :)
> Faktycznie było to fajnie, chociaż propel miał swoje ogromne minusy
> (metody statyczne do obsługi zapytań baz danych).

Propela za bardzo nie znam. Wieki temu go macałem.

> Laravel też chyba na statykach jedzie, z tego co pamiętam?

Nie, jedynie w przypadku ręcznego pisania zapytań w stylu DB::select(...).
Query builder jest obiektowy, eloquent tak samo. Ale jest bardzo ściśle
powiązany z resztą frameworka, także może być trudno skorzystać poza nim.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Sat, 27 Jan 2018 23:08:02 +0100, Marek S napisał(a):

> Chodzi mi o to, że nie da się w zasadzie tak napisać aplikacji aby nie 
> miała jednego, nadrzędnego singletona. Cała aplikacja bazuje na modelu 
> DI ale jej "kernel" _zawsze_ musi być zainicjowany globalnie. A jeśli 
> jest zainicjowany globalnie to staje się singletonem.

Nie. Przeczytaj jeszcze raz definicję singletona. Obiekt zainicjowany
globalnie jest, cóż, po prostu obiektem zainicjowanym globalnie. I niczym
więcej. Jak go zapakujesz w klasę statyczną i zapewnisz, że jest tworzona
tylko jedna instancja tego obietu, to otrzymujesz singletona.

> Może to abstrakcyjnie zilustruję. Niech oprogramowanie DI przypomina 
> książkę. Są w niej rozdziały, w rozdziałach zdania, w zdaniach wyrazy. 
> Widać hierarchię. Każdy z wyrazów, rozdziałów ma dostęp do książki, 
> której część stanowi. Książka pozwala na współzależność rozdziałów.

Mieszasz pojęcia. DI to zupełnie inny wzorzec i nie ma nic wspólnego z
powyższym opisem. To jest jedynie sposób przekazywania obiektów do innych
obiektów.

> A od czego zależy sama książka? Od niczego! Stanowi samoistny byt. 
> Singleton! :-) Uruchamiamy na serwerze 10 aplikacji lub 10 instancji tej 
> samej aplikacji - mamy 10 singletonów.

Mamy 10 instancji, nic więcej.

> Czy robię jakiś błąd myślowy?

Tak. Przypisujesz pojęciom inne znaczenia. Z tego możesz wywieść dowolny
wniosek.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Sat, 27 Jan 2018 23:07:29 +0100, Wojciech Bancer napisał(a):

> Laravel też chyba na statykach jedzie, z tego co pamiętam?

Ach, pytasz generalnie o Laravela. Nie do końca. Twórca wymyślił sobie coś,
co nazwał fasadą i działa to tak, że wywołanie statyczne jest
przekształcane w wywołanie kontenera IoC. Czyli pisząc DB::table() tak
naprawdę wołasz app('db')->table(). Społeczność jest mocno podzielona w
sprawie tego rozwiązania i nie dziwię się temu. Ale nie trzeba z tego
korzystać.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 27-01-2018 o 23:02, Wojciech Bancer pisze:

> A skąd założenie że jest singletonem?

To nie założenie. Bo (raczej) nie może być czymkolwiek innym.


> Gdzie tu widzisz wzorzec singletona?

W tym, że jest obiekt nadrzędny nad wszystkimi, który tylko można 
zainicjować i nic więcej. W całej aplikacji zawiera tylko jedno 
zainicjowanie. Jest singlem.

> Rozumiesz czym jest ten wzorzec?

Być może. Sprostuj mnie jeśli błędnie to ujmuję.

> No to mamy niezgodę, bo ja nie uznaję dowolnego pojedynczego obiektu
> za singletona tylko dlatego że jest jeden :P

No więc jesteśmy coraz bliżej zdefiniowania rozbieżności interpretacji. 
:-) Nie bardzo rozumiem czemu przyjmujesz definicję z Wiki za 
nieprawdziwą. Może małymi krokami i na przykładzie.

Ok, powiedz mi na podstawie kodu:

class cosTam() {}
$obj=new cosTam();

Powyższe to całość aplikacji. Nie ma więcej kodu. To jest jedna klasa i 
obiekt z niej. Czy jest to wzorzec singletona czy DI czy cokolwiek? Bo 
dla mnie to czysty singleton zgodny z definicją Wiki. Załóżmy, że 
odpowiesz mi cokolwiek. Teraz dostawiamy jedną metodę do tej klasy. Czy 
coś się zmienia w tym co mi odpowiedziałeś? Pewnie nie. No to lećmy 
dalej: budujemy inne klasy, które zaczynają korzystać z powyższej bo 
powyższa np. udostępnia połączenie do bazy a inne go pragną. Od jakiego 
momentu powyższa klasa przestaje być singletonem a zaczyna być DI?

Wyjaśnię jak ja rozumuję. Jedyna klasa w całej aplikacji musi być 
singletonem. Nawet jeśli dostawi się do niej mnóstwo właściwości i metod 
to nic się nie zmieni. Jeśli dostawimy teraz inne klasy, które 
komunikują się z powyższą, to mogą one zacząć stanowić model DI. Wtedy 
mówimy, że wszystkie pozostałe klasy "pracują" w/g wzorca DI. Jednakże 
nie pozwala to przechrzcić klasy nadrzędnej. Ona udostępnia interfejs DI 
ale sama jest singletonem.

Twój ruch :-)

-- 
Pozdrawiam,
Marek

W dniu 27-01-2018 o 23:26, Borys Pogoreło pisze:

> Nie. Przeczytaj jeszcze raz definicję singletona. Obiekt zainicjowany
> globalnie jest, cóż, po prostu obiektem zainicjowanym globalnie. I niczym
> więcej. Jak go zapakujesz w klasę statyczną i zapewnisz, że jest tworzona
> tylko jedna instancja tego obietu, to otrzymujesz singletona.

Pewnie na czymś się zafiksowałem błędnie. W/g mnie sigleton nie ma nic 
wspólnego z koniecznością używania obiektów statycznych. Może, ale nie 
musi.

Np. niech naszą aplikację inicjuje klasa "kernel". Ona wewnątrz siebie 
m.in. tworzy obiekt klasy Database. Klasa Database zaraz po 
zainicjowaniu tworzy połączenie i udostępnia nie-statyczne metody do 
realizacji zadań w ramach tego połączenia. Kernel zapewnia, że tylko 
jedna instancja tejże klasy powstanie. Wszystkie inne obiekty 
korzystające z kernela zyskują automatycznie dostęp do bazy danych. 
Zgodnie z tym co napisałeś, skoro kernel tworzy tylko jedną instancję 
bazy danych, to jest już singletonem?

Bo jeśli tak, to na przykładzie bazy danych - jak inaczej tworzyć z nią 
komunikację? Za każdym razem otwierać nowe połączenie? To zabójstwo dla 
wydajności przecież.

> Tak. Przypisujesz pojęciom inne znaczenia. Z tego możesz wywieść dowolny
> wniosek.

Ok. To może inaczej: sposób wykorzystania klasy nadrzędnej może zmienić 
jej definicję wzorca z singletona na DI? Pytanie stąd, że dla mnie 
wzorzec zaczyna się pomiędzy interfejsem klasy nadrzędnej a resztą 
otoczenia i nie rzutuje na nazewnictwo wzorca współpracy danej klasy z 
otoczeniem. Jednakże sama klasa nadrzędna nie stanowi nigdy wzorca 
innego niż singleton. Czyli jeden projekt informatyczny jest singletonem 
w pierwszych liniach kodu a cała reszta komunikacji z singletonem może 
odbywać się zgodnie ze wzorcem DI. Co nie powoduje iż na kolejnym etapie 
zagnieżdżenia znów jakiegoś singletona zastosujemy otrzymując wzorzec 
mieszany dla całości.

Czy to nie tak działa definicja wzorca?

-- 
Pozdrawiam,
Marek

On 2018-01-27, Marek S <precz@spamowi.com> wrote:

[...]

>> Gdzie tu widzisz wzorzec singletona?
>
> W tym, że jest obiekt nadrzędny nad wszystkimi, który tylko można 
> zainicjować i nic więcej. W całej aplikacji zawiera tylko jedno 
> zainicjowanie. Jest singlem.

To nie jest definicja wzorca singletona.

[...]

>> za singletona tylko dlatego że jest jeden :P
>
> No więc jesteśmy coraz bliżej zdefiniowania rozbieżności interpretacji. 
>:-) Nie bardzo rozumiem czemu przyjmujesz definicję z Wiki za 
> nieprawdziwą. Może małymi krokami i na przykładzie.
>
> Ok, powiedz mi na podstawie kodu:
>
> class cosTam() {}
> $obj=new cosTam();
>
> Powyższe to całość aplikacji. Nie ma więcej kodu. To jest jedna klasa i 
> obiekt z niej. Czy jest to wzorzec singletona czy DI czy cokolwiek?

Nie. Singleton ma prywatny konstruktor i nie pozwala na stworzenie obiektu
poza kontrolą tegoż singletona. W innym wypadku:
1) nie jesteś w stanie zagwarantować globalności obiektu
2) nie jesteś w stanie zagwarantować, że obiekt jest stworzony raz.

Singleton to coś w stylu:

class cosTam() {
  private static $instance = null;
  private function __construct() {}
  public static function getInstance() {
    if (self::$instance == null) {
      self::$instance = new Singleton();
    }

    return self::$instance;
  }
}

W Java masz podobnie:
https://en.wikipedia.org/wiki/Singleton_pattern#Implementation

Każdy singleton zakłada kontrolę nad tworzeniem instancji takiego
obiektu. Jeśli jej nie ma, to nie jest to singleton.

To że sobie zrobisz klasę i użyjesz raz nie czyni z niej singletona.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

Dnia Sat, 27 Jan 2018 23:56:37 +0100, Marek S napisał(a):

> jedna instancja tejże klasy powstanie. Wszystkie inne obiekty 
> korzystające z kernela zyskują automatycznie dostęp do bazy danych. 
> Zgodnie z tym co napisałeś, skoro kernel tworzy tylko jedną instancję 
> bazy danych, to jest już singletonem?

Jeśli tworzy jednorazowo i zawsze zwracą *tę samą* instancję, to tak - mamy
do czynienia z singletonem.

Ty utożsamiasz z singletonem dowolny obiekt, który został tylko raz
utworzony.

> Ok. To może inaczej: sposób wykorzystania klasy nadrzędnej może zmienić 
> jej definicję wzorca z singletona na DI? Pytanie stąd, że dla mnie 
> wzorzec zaczyna się pomiędzy interfejsem klasy nadrzędnej a resztą 
> otoczenia i nie rzutuje na nazewnictwo wzorca współpracy danej klasy z 
> otoczeniem. Jednakże sama klasa nadrzędna nie stanowi nigdy wzorca 
> innego niż singleton. Czyli jeden projekt informatyczny jest singletonem 
> w pierwszych liniach kodu a cała reszta komunikacji z singletonem może 
> odbywać się zgodnie ze wzorcem DI. Co nie powoduje iż na kolejnym etapie 
> zagnieżdżenia znów jakiegoś singletona zastosujemy otrzymując wzorzec 
> mieszany dla całości.
> 
> Czy to nie tak działa definicja wzorca?

Przeczytałem to cztery razy i dalej nie rozumiem. Mieszasz różne wzorce,
które nie mają ze sobą związku. Z DI możesz co najwyżej porównywać service
locator, bo pełnią podobną rolę

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

> Nie musisz mi tłumaczyć podstawowych pojęć. Ja się pytam, czy znasz jakieś
> różnice w kontekście wydajności przy obsłudze parametrów w funkcji, a w
> metodzie.
> 
> -- 
> Borys Pogoreło
> borys(#)leszno,edu,pl

Miałem na myśli sposób odkładania funkcji w pamięci, a funkcji w klasach. O tym że przekazując zmienna do klasy przekazujemy jej kopie (chyba, że zdeklarujemy inaczej), przekazując obiekt przekazujemy jego adres.

Funkcja żyje w pamięci cały czas i każde jej użycie to przeładowanie stosu załadowanie funkcji zakończenie i zwolnienie stosu.

Klasa żyje w pamięci gdy utworzymy jej instancje ale tylko z atrybutami. Natomiast funkcje klas odkładane są w pamięci w postaci adresów do funkcji. W rezultacie wywołując funkcje z klasy odwiedzamy adres w pamięci do funkcji. 

Uruchamiając obiekt też mamy przeładowanie stosu -> załadowanie obiektu z atrybutami i wszystkimi adresami do funkcji. Tworząc wielokrotność obiektu mamy ciągle w każdej instancji ten sam adres do tej samej metody.
Jeśli wywołujemy funkcje jedna po drugiej to one nie wymagają już przeładowania stosu.

Między innymi dlatego tak dobry jest polimorfizm i dziedziczenie. Bo każda klasa z której dziedziczymy zawiera adresy metod a nie same metody w swoim ciele w pamięci. 

Mam nadzieje że dość jasno się wyraziłem. Jak coś piszcie.

On Sat, 27 Jan 2018 22:43:37 +0100, Borys Pogoreło wrote:

>> Zamiast tony if'ów stosuje się polimorfizm. Odkąd PHP jest obiektowe chyba
>> to jest lepsza droga?
> 
> A gdzie masz w PHP polimorfizm?

Eeee.... czyli mnie nabrali, że PHP jest obiektowy?
Jeśli tak to sorki, jak pisałem jestem początkujący w tym języku, tak
daleko jeszcze nie doszedłem i teraz mnie totalnie zastrzeliłeś.

-- 
pozdrawiam
Roman Tyczka

Dnia Mon, 29 Jan 2018 08:48:14 +0100, Roman Tyczka napisał(a):

>>> Zamiast tony if'ów stosuje się polimorfizm. Odkąd PHP jest obiektowe chyba
>>> to jest lepsza droga?
>> 
>> A gdzie masz w PHP polimorfizm?
> 
> Eeee.... czyli mnie nabrali, że PHP jest obiektowy?

Tego akurat z obiektowości nie zapożyczyli. Listę argumentów metody można
jedynie rozszerzać.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl