Forum PHP.pl

Dziękuję.

http://php7-tutorial.com

Ciekawa strona, można się przetestować "na żywo" czy umiemy przepisać skrypt pod php7.

Składał ktoś PIT-37 po terminie? Teoretycznie grozi za to mandat karny, ale czy go wystawiają za niewielkie spóźnienie?

Ten post edytował WebCM 29.04.2016, 21:21:45

Zanieś ręcznie do US i dołącz do tego "czynny żal" i powinno być po kłopocie.

PS. ZUS bardziej jest bezwzględny (IMG:style_emoticons/default/smile.gif) US przymyka oko na takie drobne rzeczy.

Co sądzicie Panowie o takim stylu kodowania, spotkałem się z nim podczas generowania różnych "rzeczy" z poziomu konsoli symfony, gdzie np wygenerowany formularz taką konwencję przyjmuje.

[PHP] pobierz, plaintext 
 
$user
    ->setName('name')
    ->setSurname('surname')
    ->setAddress('address')
    ->setAccount('...')
;
[PHP] pobierz, plaintext 

Pytam z czystej ciekawości (IMG:style_emoticons/default/wink.gif)

Ten post edytował Fred1485 2.05.2016, 19:23:40

Ja tam lubię method chaining ;d Wkurza mnie pisanie wszystkiego po kilka razy - tak mam raz obiekt do którego chcę się odwołać, a później tylko piszę po kolei co chce zrobić (IMG:style_emoticons/default/smile.gif)

Czytelnie...

[PHP] pobierz, plaintext 
$user->setName('name')
    ->setSurname('surname')
    ->setAddress('address')
    ->setAccount('...');
[PHP] pobierz, plaintext 

@up Też taki sposób zapisu bardziej mi odpowiada. Ten średnik w nowej linii to głupota (IMG:style_emoticons/default/tongue.gif)

To też kwestia gustu (IMG:style_emoticons/default/smile.gif) Imo czytelniej jest jeśli średnik jest w nowej linii bo wtedy mam oddzielony taki jakby blok jak w przypadku klamerek. (IMG:style_emoticons/default/smile.gif) Poza tym łatwiej mi później dodać nową linijkę na końcu. Tak samo w przypadku tablic, zawsze po ostatnim elemencie dostawiam przecinek (IMG:style_emoticons/default/wink.gif)

Też jestem za fluent interface ("method chaining").
Praktycznie używam gdzie się da jak tylko biblioteki oferują, lub sam coś robię.
Mniej do pisania przez co też czytelniej wiele dla mózgu (IMG:style_emoticons/default/biggrin.gif)

Nie lubię fluent interface. Nie przestrzega prawa Demeter, nigdy nie wiadomo, jaki typ obiektu jest po strzałkach ani jaki rezultat zwraca funkcja. Przekazując sobie każdą wartość do zmiennej nadaje się jej nazwę, przez co wiadomo, czym ten rezultat jest.

Zaraz posypie się hejt wszystkich lubiących fluent.

Kolejnym ważnym aspektem przeciw fluent jest to, że łamie się SRP, ponieważ kilkakrotnie zmienia się kontekst a co za tym idzie, robi się wiele rzeczy na raz. Nie mówiąc już o testowaniu, które jest coraz trudniejsze wraz ze wzrostem metod, które uruchamiamy jedna po drugiej (niezależnie od tego, czy używamy fluent, czy nazywamy sobie rezultaty funkcji).

Ten post edytował mrc 2.05.2016, 19:59:51

Mógłbyś rozwinąć pierwsze zdanie? (To że nie wiadomo jaki typ obiektu).
Co do rezultatu. Fluent` zwarca obiekt, domyslnie by pewnie nic nie zwracał (gdyby się go nie zastosowało), bo skoro metoda mogła by zwrócić coś innego to większość osób by pewnie tak zrobiło..


Do tego wiele osób to używa według mnie.

### to nie hejt tylko pytanie ###

@Ksar, programując w C++ masz coś takiego:



Gubisz tutaj typ, nie masz informacji o tym, co zwraca doSomeStuff oraz doSomeOtherStuff().
Możesz to zamienić na:



W pierwszym nie wiesz, co zwracają funkcje, w drugim wiesz. W pierwszym nie przyjdzie Ci na myśl to, że dwie pierwsze funkcje zwracają ten sam typ, w drugim masz jasno wszystko.
Ofc. przykład podałem w C++, ponieważ łatwiej jest zauważyć różnicę. Podobnie to działa w JS, PHP, Java czy innych C#.

Zaraz mi powiesz, że czytelność jest dla Ciebie najważniejsza. I przez takie gadanie powstają bagniste spaghetti nie trzymające się żadnych zasad.

Co do robienia wielu rzeczy na raz - z tego co kojarzę jesteś młodym programistą, więc zapamiętaj raz na zawsze: każda funkcja którą napiszesz ma robić tylko jedną rzecz. Jeżeli używasz gdzieś fluent, to jest spore ryzyko tego, że funkcja używająca go nie robi jednej rzeczy na raz.

Ale debila to ze mnie nie rób, bo pisałem tak:

^ ja się w to wliczam.
Co do funkcji(metody) - robię tak, zaskocze tez cb ze fluent dodaje gdy juz wszystko zrobione i przetestowane. A nie jak ci się zdaje na początku lub w trakcie.

Różnica w czytelności nie jest tak wielka jakby mogło się wydawać na pierwszy rzut oka:

[PHP] pobierz, plaintext 
$user = $sth->getUser();
$user->setName('name')
        ->setSurname('surname')
        ->setAddress('address')
        ->setAccount('...');
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
$user = $sth->getUser();
$user->setName('name');
$user->setSurname('surname');
$user->setAddress('address');
$user->setAccount('...');
[PHP] pobierz, plaintext 

Zawsze gdzieś będzie fragment kodu, który zbierze wywołanie kilku rzeczy na raz (IMG:style_emoticons/default/tiredsmiley.gif)

Natomiast przykład powyżej pokazują, że fluent przy niewielkiej (IMHO) poprawie czytelności zmienia ilość zadań wykonywanych przez settery. W drugim przypadku metody te tylko zapisują dane, zmieniając aktualny stan obiektu, natomiast w pierwszym wykonują 2 działania: zapis i odczyt/zwrot wartości.

Skoro już mowa o fluent to do poczytania http://ocramius.github.io/blog/fluent-interfaces-are-evil/ (IMG:style_emoticons/default/wink.gif)

Też mnie zawsze fluent API trochę mierzi, ale z drugiej strony: czy takie jQuery byłoby aż tak popularne, gdyby tego nie miało? To jest de facto znak rozpoznawczy tej biblioteki. W obecnej chwili, jak pisze się tego typu liba w JS, to po prostu nie da się nie zaimplementować fluent API. Ba, nawet stworzono liba, żeby takie fluent API wprowadzić bezpośrednio do DOM → http://lea.verou.me/chainvas/

Nie mówię, że to jest złe czy dobre – bardziej się zastanawiam skąd aż taka popularność tego w pewnym segmencie JS devu. I nie, odpowiedź "bo to JS" nie jest poprawna (IMG:style_emoticons/default/wink.gif)

tak tylko w 90% w JQ wykonujesz coś na obiekcie i nie interesuję Cie co ta funkcja zwraca, bo liczy się efekt, a nie sam wynik.

Ok… Ale czym się zatem różni:

od:

? (IMG:style_emoticons/default/wink.gif)

Zasada jest dokładnie taka sama: liczy się dla nas efekt, nie wynik. Więc skoro w PHP jest to przez wielu uważane za anti-pattern, to dlaczego w JS – już nie?

No w tym przypadku nie ma różnicy, ale w php częściej to wynik ma znaczenie, bo z tym $user coś się potem robi, w JQ też czasem, ale w wielu przypadkach już same wywołanie tego na jakimś elemencie daje nam oczekiwany rezultat. A czy nie jest uznawane za anti-pattern to bym polemizował, bardzie to kwestia tego iż się przyjęło, w takich bibliotekach bo tam modyfikujesz pewien stan obiektu DOM. A druga sprawa, że ten język jest silnie prototypowy i tak został zbudowany. ES2015 jest zbyt młody, żeby mówić o tym co w innych językach wypracowane zostało już przez lata.

A nawet w twoim przykładzie, setter sugeruje, że ustawiasz jakaś właściwość, ale nie mówi nic o fakcie iż zostanie zwrócony obiekt.
To by musiało wyglądać wtedy tak:

[PHP] pobierz, plaintext 
$user = new User()
    ->setNameAndReturnUser( 'Name' )
    ->setSurnameAndReturnUser( 'Surname' )
[PHP] pobierz, plaintext