🚀 go-pugleaf

W dniu 2019-08-03 o 16:58, Jivanmukta pisze:
> Nie podoba mi sie w PHP:
> 1. że nie deklaruje się zmiennych lokalnych, przydałoby się: var $zmienna;

Co znaczy "lokalnych"? Na poziomie klas czy poszczególnych metod od 
zarania dziejów można je deklarować.

> 2. że empty('0') === true i nie ma isempty() t.że isempty('0') === false

Więc użyj zwyczajnie $zmienna==="" zamiast funkcji, którą sam uważam za 
dziwaczną i średnio przydatną.

> 3. dynamiczne typy zmiennych

Typowanie dynamiczne istniało od zawsze i zaczyna się to zmieniać. Co 
prawda typowanie zmiennych w parametrach funkcji istnieje już od 
dłuższego czasu.

Od wersji PHP 7.4 wreszcie będzie można wymuszać typowanie pozostałych 
zmiennych.


> 4. bałagan w nazwach funkcji np. gettype() i get_class()

Niestety tak będzie. A co by się stało gdyby zlikwidowano get_class na 
rzecz getclass? Wszystkie aplikacje napisane wcześnie miałyby przestać 
działać?

Logo PHP to słoń. Często nieporadny i sieje spustoszenie w rękach 
nieobytych w nim programistów. Przy stosowaniu technik OOP i innych 
praktyk z serii PSR, łatwo jest radzić sobie z niedogodnościami i 
uporządkować wiele rzeczy.

> A co was denerwuje w PHP?

Marudzenie adeptów PHP :-D

-- 
Pozdrawiam,
Marek

On Sun, 4 Aug 2019 22:00:14 +0200, Marek S wrote:

>> 4. bałagan w nazwach funkcji np. gettype() i get_class()
> 
> Niestety tak będzie. A co by się stało gdyby zlikwidowano get_class na 
> rzecz getclass? Wszystkie aplikacje napisane wcześnie miałyby przestać 
> działać?

Wystarczyłoby zrobić aliasa getclass() do get_class() i pozostawić obie
przy czym starą oznaczyć jako deprecated i za 3 wersje usunąć. Da się?
 
> Logo PHP to słoń. Często nieporadny i sieje spustoszenie w rękach 
> nieobytych w nim programistów. Przy stosowaniu technik OOP i innych 
> praktyk z serii PSR, łatwo jest radzić sobie z niedogodnościami i 
> uporządkować wiele rzeczy.
> 
>> A co was denerwuje w PHP?
> 
> Marudzenie adeptów PHP :-D

Raczej zdziwienie po wejściu w PHP z języków od początku przemyślanych.

-- 
pozdrawiam
Roman Tyczka

W dniu 2019-08-05 o 07:52, Roman Tyczka pisze:

> Wystarczyłoby zrobić aliasa getclass() do get_class() i pozostawić obie
> przy czym starą oznaczyć jako deprecated i za 3 wersje usunąć. Da się?

No i też można zrobić aliasa od gettype do get_type, a potem usunąć 
gettype. Być może w kolejnej wersji odwrotnie. Pytanie: która zmiana 
zadowoli użytkowników PHP?

Moim zdaniem żadna.

>>> A co was denerwuje w PHP?
>>
>> Marudzenie adeptów PHP :-D
> 
> Raczej zdziwienie po wejściu w PHP z języków od początku przemyślanych.

A są takowe? Z tego, co się orientuję, to np. w C# wprowadzono typ 
"auto" niedawno, wprowadzając tym samym to, od czego ucieka się w PHP 7.4.

-- 
Pozdrawiam,
Marek

On Sat, 10 Aug 2019 00:53:15 +0200, Marek S wrote:

>> Wystarczyłoby zrobić aliasa getclass() do get_class() i pozostawić obie
>> przy czym starą oznaczyć jako deprecated i za 3 wersje usunąć. Da się?
> 
> No i też można zrobić aliasa od gettype do get_type, a potem usunąć 
> gettype. Być może w kolejnej wersji odwrotnie. Pytanie: która zmiana 
> zadowoli użytkowników PHP?
> 
> Moim zdaniem żadna.

A moim trzeba uciekać od nazw z podkreśleniami, bo to jest dziwadło w
świecie języków.
 
>>>> A co was denerwuje w PHP?
>>>
>>> Marudzenie adeptów PHP :-D
>> 
>> Raczej zdziwienie po wejściu w PHP z języków od początku przemyślanych.
> 
> A są takowe? Z tego, co się orientuję, to np. w C# wprowadzono typ 
> "auto" niedawno, wprowadzając tym samym to, od czego ucieka się w PHP 7.4.

O ile mi wiadomo to typ auto nie jest czymś co działa jak brak typu w PHP,
typ auto jest używany w jednoznacznych sytuacjach do inferencji typu
właściwego czyli "zgadnięcia" przez kompilator o jaki typ chodzi. Nie jest
tak, że do typu auto możesz sobie raz przypisać integera a raz stringa.

-- 
pozdrawiam
Roman Tyczka

Marek S pisze:
> W dniu 2019-08-03 o 16:58, Jivanmukta pisze:
>> 2. że empty('0') === true i nie ma isempty() t.że isempty('0') === false
> 
> Więc użyj zwyczajnie $zmienna==="" zamiast funkcji, którą sam uważam za 
> dziwaczną i średnio przydatną.
Czyli średnio umiesz użyć tej funkcji, a ma ona bardzo przydatną zaletę:
$DATA=explode('<separator-one-char>', $data);

if ($DATA['property1']==1) { ... }
Tu będzie ostrzeżenie, jeśli indeks 'property1' nie istnieje.

if (isset($DATA['property1']) && $DATA['property1']==1) { ... }
To zadziała, ale zbyt rozwlekłe skoro można krócej.

if (!empty($DATA['property1'])) { ... }
Oczywiście to ma sens w przypadkach, gdy sprawdzamy obecność danej opcji,
np: pole checked z formularza HTML, jeśli zaznaczone, to _GET/_POST,
jest określona wartość dla danego pola, gdy nie zaznaczone,
to tej wartości nie ma w ogóle.
Albo powyższy przypadek kiedy lista właściwości przechowywana jest
w postaci ciągu znaków rozdzielonych separatorami.

>> A co was denerwuje w PHP?
> 
> Marudzenie adeptów PHP :-D
Prawda, choć nie jestem programista PHP,
czasem tylko jakiś prosty skrypt napiszę.

Dnia Sun, 11 Aug 2019 20:23:34 +0200, PawelS pawel(at)wbcd(dot)pl
napisał(a):

> Albo powyższy przypadek kiedy lista właściwości przechowywana jest
> w postaci ciągu znaków rozdzielonych separatorami.

Checkbox - OK, dobry przykład. Ale przetwarzanie powyższego wysypie się na
pierwszym wystąpieniu ciagu znaków '0', co jest największym problemem
funkcji (konstruktu) empty().

Poza tym nie do końca rozumiem przytoczony przykład. `explode()` zwróci
tablicę indeksowaną numerycznie.

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

Dnia Sat, 3 Aug 2019 16:58:38 +0200, Jivanmukta napisał(a):

> Nie podoba mi sie w PHP:
> 1. że nie deklaruje się zmiennych lokalnych, przydałoby się: var $zmienna;

Deklaracje zmiennych mają swoje zakresy, czego konketnie tu potrzebujesz?

> 2. że empty('0') === true i nie ma isempty() t.że isempty('0') === false

Cóż, legacy. Ale taką funkcję możesz sobie w każdej chwili dopisać.

> 3. dynamiczne typy zmiennych

To akurat zaleta IMHO, a po ucywilizowaniu języka w 7.x nawet trudno sobie
strzelić w stopę pilnując typów zmiennych.

> 4. bałagan w nazwach funkcji np. gettype() i get_class()

Rasmus i jego genialne pomysły sprzed lat + święta zgodność wstecz obecnie.
No co zrobisz, nic nie zrobisz.

> A co was denerwuje w PHP?

Coraz mniej. Może to syndrom sztokholmski po tylu latach.

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

Borys Pogoreło pisze:
> Dnia Sun, 11 Aug 2019 20:23:34 +0200, PawelS pawel(at)wbcd(dot)pl
> napisał(a):
> 
>> Albo powyższy przypadek kiedy lista właściwości przechowywana jest
>> w postaci ciągu znaków rozdzielonych separatorami.
> 
> Checkbox - OK, dobry przykład. Ale przetwarzanie powyższego wysypie się na
> pierwszym wystąpieniu ciagu znaków '0', co jest największym problemem
> funkcji (konstruktu) empty().
> 
> Poza tym nie do końca rozumiem przytoczony przykład. `explode()` zwróci
> tablicę indeksowaną numerycznie.
OK, teraz widzę, że nie dopisałem tego co istotne:
$DATA=explode('<separator-one-char>', $data);
$DATA=array_flip($DATA);
parametry teraz będą indeksami tablicy,
a pierwszy z listy parametr będzie miał wartość 0.
W ten sposób zauważyłem, że w pewnym projekcie,
ktoś łatwo zapisuje ustawienia opcji typu bool,
w sensie zaznaczony dany parametr lub nie
(które potem są zapisywane i odczytywane z bazy danych).
Teraz czy dany parametr jest włączony wystarczy sprawdzić
jego obecność poprzez wspomnianą funkcję emtpy():
if (!empty($DATA['keyword'])) { /* data funkcjonalność jest dostępna  */ }
else                          { /* dana funkcjonalność niedostępna */ }
Tak jak napisałem przy użyciu empty() unika się ostrzeżeń,
że dany keyword nie istnieje, a jednocześnie nie trzeba
dodatkowo wywoływać isset() i potem porównywać (jest krócej).
Oczywiście powyższa funkcja ma sens w określonych przypadkach.

W dniu 2019-08-10 o 14:21, Roman Tyczka pisze:

>> No i też można zrobić aliasa od gettype do get_type, a potem usunąć
>> gettype. Być może w kolejnej wersji odwrotnie. Pytanie: która zmiana
>> zadowoli użytkowników PHP?
>>
>> Moim zdaniem żadna.
> 
> A moim trzeba uciekać od nazw z podkreśleniami, bo to jest dziwadło w
> świecie języków.

Jasne... tylko zwróć uwagę, że użyłeś słowa "języków". Pod tą kategorię 
podchodzą również języki kompilowane. PHP nie należy do tej grupy. Po 
zmianie, za jaką optujesz, serwisy WWW zwyczajnie upadną. Błędy zaczną 
ujawniać się w trakcie używania poszczególnych funkcji aplikacji.

W językach kompilowanych, zwyczajnie nie dałoby się skompilować kodu i 
będzie trzeba poprawić te funkcje. W efekcie po takich zmianach kod 
będzie działał.

Serio jesteś zwolennikom upadku sporego procentu aplikacji PHP w imię 
wdrażania polityki poprawności?

>> A są takowe? Z tego, co się orientuję, to np. w C# wprowadzono typ
>> "auto" niedawno, wprowadzając tym samym to, od czego ucieka się w PHP 7.4.
> 
> O ile mi wiadomo to typ auto nie jest czymś co działa jak brak typu w PHP,
> typ auto jest używany w jednoznacznych sytuacjach do inferencji typu
> właściwego czyli "zgadnięcia" przez kompilator o jaki typ chodzi. Nie jest
> tak, że do typu auto możesz sobie raz przypisać integera a raz stringa.

Poprosiłem kolegów pracujących w C# o testy. Przypisali do tej samej 
zmiennej i iteger'a i string'a. Program skompilował się bez problemu.

-- 
Pozdrawiam,
Marek

W dniu 2019-08-11 o 20:23, PawelS pawel(at)wbcd(dot)pl pisze:

>> Więc użyj zwyczajnie $zmienna==="" zamiast funkcji, którą sam uważam 
>> za dziwaczną i średnio przydatną.
> Czyli średnio umiesz użyć tej funkcji, a ma ona bardzo przydatną zaletę:
> $DATA=explode('<separator-one-char>', $data);

Możliwe, że średnio. Szczególnie, że nie wiem kompletnie, o czym w ogóle 
piszesz. A już w szczególności, gdy piszesz poniższe.

> if ($DATA['property1']==1) { ... }
> Tu będzie ostrzeżenie, jeśli indeks 'property1' nie istnieje.

No i? Czego to ma dowodzić?

> 
> if (isset($DATA['property1']) && $DATA['property1']==1) { ... }
> To zadziała, ale zbyt rozwlekłe skoro można krócej.
> 
> if (!empty($DATA['property1'])) { ... }
> Oczywiście to ma sens w przypadkach, gdy sprawdzamy obecność danej opcji,

No właśnie. Użyłeś kluczowego słowa "gdy". Funkcja g... prawdę Ci 
zwróci, gdy property1 będzie wynosiło numeryczne 0 lub pusty string.

> Prawda, choć nie jestem programista PHP,
> czasem tylko jakiś prosty skrypt napiszę.

No więc właśnie w tym rzecz. Ja w PHP siedzę od wieków. "empty()" 
porzuciłem już dawno z powodu tego, że wymaga sprawdzanie Twojego  "gdy".

-- 
Pozdrawiam,
Marek

W dniu 12.08.2019 o 21:50, Borys Pogoreło pisze:
> Dnia Sat, 3 Aug 2019 16:58:38 +0200, Jivanmukta napisał(a):
> 
>> Nie podoba mi sie w PHP:
>> 1. że nie deklaruje się zmiennych lokalnych, przydałoby się: var $zmienna;
> 
> Deklaracje zmiennych mają swoje zakresy, czego konketnie tu potrzebujesz?
> 

Jak napiszesz:

$mojaZmienna = 1;
...
if (!isset($mojaZmiana)) { // literówka; chciałem: !isset($mojaZmienna)
   $mojaZmienna = 2;
}

to program się skompiluje i będzie jakoś działał, a chciałbym mieć błąd 
kompilacji, że nie zadeklarowana zmienna.

> 
>> 3. dynamiczne typy zmiennych
> 
> To akurat zaleta IMHO, a po ucywilizowaniu języka w 7.x nawet trudno sobie
> strzelić w stopę pilnując typów zmiennych.
> 

Czy w kontekście programowania WWW dynamiczne typy zmiennych mają 
zaletę? Na przykład?

Dnia Tue, 13 Aug 2019 18:21:29 +0200, PawelS pawel(at)wbcd(dot)pl
napisał(a):

> $DATA=explode('<separator-one-char>', $data);
> $DATA=array_flip($DATA);
> parametry teraz będą indeksami tablicy,
> a pierwszy z listy parametr będzie miał wartość 0.

Nie prościej po prostu zserializować JSON? Taki sposób zapisu wnosi więcej
problemów, niż rozwiązuje.

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

Dnia Wed, 14 Aug 2019 12:38:56 +0200, Jivanmukta napisał(a):

> if (!isset($mojaZmiana)) { // literówka; chciałem: !isset($mojaZmienna)
>    $mojaZmienna = 2;
> }
> 
> to program się skompiluje i będzie jakoś działał, a chciałbym mieć błąd 
> kompilacji, że nie zadeklarowana zmienna.

Przecież taki jest właśnie cel konstruktu isset(). Sprawdza o co pytasz,
nie może zgadywać. Trzeba uważać.

Do tego w PHP zmienne mogą się pojawić niejawnie, np. przez extract(), więc
kompilator nic nie może założyć na podstawie kodu.

>> To akurat zaleta IMHO, a po ucywilizowaniu języka w 7.x nawet trudno sobie
>> strzelić w stopę pilnując typów zmiennych.
> 
> Czy w kontekście programowania WWW dynamiczne typy zmiennych mają 
> zaletę? Na przykład?

Choćby dlatego, że HTTP jest protokołem tekstowym, więc konwersja typów
ułatwia życie, bez konieczności wprowadzania rzutowań na każdym kroku.

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

W dniu 14.08.2019 o 14:01, Borys Pogoreło pisze:
> Dnia Wed, 14 Aug 2019 12:38:56 +0200, Jivanmukta napisał(a):
> 
>> if (!isset($mojaZmiana)) { // literówka; chciałem: !isset($mojaZmienna)
>>     $mojaZmienna = 2;
>> }
>>
>> to program się skompiluje i będzie jakoś działał, a chciałbym mieć błąd
>> kompilacji, że nie zadeklarowana zmienna.
> 
> Przecież taki jest właśnie cel konstruktu isset(). Sprawdza o co pytasz,
> nie może zgadywać. Trzeba uważać.
> 
Napisałem kiedyś kawałek kodu podobny do powyższego i kod się kompiował. 
Nic nie wiedziałem o literówce przez miesiąc.
Jakbym napisał:

$mojaZmienna = $x * $x + $y * $y;
$mojaZmiana = sqrt($mojaZmienna);

to też bym nic nie wiedział o literówce. Konieczność deklarowania:

var $mojaZmienna, $x, $y;

by umożliwiła wykrycie literówki w drugim przypisaniu.
Mam przyzwyczajenia z innych języków (C/C++, Pascal) gdzie deklaruje się 
zmienne.

Dnia Wed, 14 Aug 2019 14:15:03 +0200, Jivanmukta napisał(a):

> to też bym nic nie wiedział o literówce. Konieczność deklarowania:
> 
> var $mojaZmienna, $x, $y;
> 
> by umożliwiła wykrycie literówki w drugim przypisaniu.

Powtarzam, w PHP zmienne mogą pojawić się niejawnie w trakcie wykonywania
kodu. Nie ma technicznej możliwości realizacji tego bez gruntownej
przebudowy języka.

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

Borys Pogoreło pisze:
> Dnia Tue, 13 Aug 2019 18:21:29 +0200, PawelS pawel(at)wbcd(dot)pl
> napisał(a):
> 
>> $DATA=explode('<separator-one-char>', $data);
>> $DATA=array_flip($DATA);
>> parametry teraz będą indeksami tablicy,
>> a pierwszy z listy parametr będzie miał wartość 0.
> 
> Nie prościej po prostu zserializować JSON? Taki sposób zapisu wnosi więcej
> problemów, niż rozwiązuje.

Przekaż tę sugestię Jean-Philippe Lang twórcy Redmine,
tam w bazie zapisywana jest lista, tylko w takiej
trochę dziwacznej postaci (tylko włączone opcje są zapisane):

---[ ]
- :edit_project
- :select_project_modules
- :manage_members
- :manage_versions

Dla zgodności z redmine parsuje to i zapisuje w takim samym formacie.

Marek S pisze:
> W dniu 2019-08-11 o 20:23, PawelS pawel(at)wbcd(dot)pl pisze:
> 
>>> Więc użyj zwyczajnie $zmienna==="" zamiast funkcji, którą sam uważam 
>>> za dziwaczną i średnio przydatną.
>> Czyli średnio umiesz użyć tej funkcji, a ma ona bardzo przydatną zaletę:
>> $DATA=explode('<separator-one-char>', $data);
> 
> Możliwe, że średnio. Szczególnie, że nie wiem kompletnie, o czym w ogóle 
> piszesz. A już w szczególności, gdy piszesz poniższe.
> 
>> if ($DATA['property1']==1) { ... }
>> Tu będzie ostrzeżenie, jeśli indeks 'property1' nie istnieje.
> 
> No i? Czego to ma dowodzić?
> 
>>
>> if (isset($DATA['property1']) && $DATA['property1']==1) { ... }
>> To zadziała, ale zbyt rozwlekłe skoro można krócej.
>>
>> if (!empty($DATA['property1'])) { ... }
>> Oczywiście to ma sens w przypadkach, gdy sprawdzamy obecność danej opcji,
> 
> No właśnie. Użyłeś kluczowego słowa "gdy". Funkcja g... prawdę Ci 
> zwróci, gdy property1 będzie wynosiło numeryczne 0 lub pusty string.

Ok, tutaj podałem zły przykład, zwłaszcza z tym explode(),
ale z checkbox ma to sens, oczywiście można użyć również isset(),
nie pamiętam już dokładnie w jakim przypadku,
ale użycie empty() było wygodniejsze niż isset().
Być może chodziło o przypadek w którym mogę nie mieć w tablicy
danej opcji, mogę mieć pustą (czego również nie chcę)
oraz mogę mieć nie pustą opcję, a isset() będzie prawdziwe,
gdy opcja będzie pusta, a wtedy musiałbym i tak oprócz isset()
użyć empty() lub strlen()>0, a empty() powinno być szybsze.

Dnia Wed, 14 Aug 2019 19:34:31 +0200, PawelS pawel(at)wbcd(dot)pl
napisał(a):

>> Nie prościej po prostu zserializować JSON? Taki sposób zapisu wnosi więcej
>> problemów, niż rozwiązuje.
> 
> Przekaż tę sugestię Jean-Philippe Lang twórcy Redmine,
> tam w bazie zapisywana jest lista, tylko w takiej
> trochę dziwacznej postaci (tylko włączone opcje są zapisane):

Skoro musisz pracować z istniejącym kodem, to nie masz za bardzo wyjścia.
Ale podejrzewam, że tam jest po prostu jakiś mechanizm, który daje sensowny
sposób dostępu do tych flag, bez niskopoziomowej rzeźby z parsowaniem
stringów.

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

Dnia Wed, 14 Aug 2019 19:40:47 +0200, PawelS pawel(at)wbcd(dot)pl
napisał(a):

> użyć empty() lub strlen()>0, a empty() powinno być szybsze.

Wydajnosć empty() jest ostatnią rzeczą, o jaką bym się martwił w tym
przypadku...

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

Borys Pogoreło pisze:
> Dnia Wed, 14 Aug 2019 19:34:31 +0200, PawelS pawel(at)wbcd(dot)pl
> napisał(a):
> 
>>> Nie prościej po prostu zserializować JSON? Taki sposób zapisu wnosi więcej
>>> problemów, niż rozwiązuje.
>> Przekaż tę sugestię Jean-Philippe Lang twórcy Redmine,
>> tam w bazie zapisywana jest lista, tylko w takiej
>> trochę dziwacznej postaci (tylko włączone opcje są zapisane):
> 
> Skoro musisz pracować z istniejącym kodem, to nie masz za bardzo wyjścia.
> Ale podejrzewam, że tam jest po prostu jakiś mechanizm, który daje sensowny
> sposób dostępu do tych flag, bez niskopoziomowej rzeźby z parsowaniem
> stringów.
Tak, tam takowy mechanizm prawdopodobnie może być (ruby/rake/gem),
a PHP (core) takowego mechanizmu nie ma, a zewnętrznych bibliotek,
które by powyższą funkcjonalność zrealizowały nie szukałem,
także sam takie coś w postaci dwóch funkcji napisałem i działa.
Zmiany wprowadzone w bazie danych z interfejsu w PHP,
są prawidłowo wyświetlane przez redmine (działa w obydwie strony).

W dniu 2019-08-14 o 19:40, PawelS pawel(at)wbcd(dot)pl pisze:

>>
>> No właśnie. Użyłeś kluczowego słowa "gdy". Funkcja g... prawdę Ci 
>> zwróci, gdy property1 będzie wynosiło numeryczne 0 lub pusty string.
> 
> Ok, tutaj podałem zły przykład, zwłaszcza z tym explode(),
> ale z checkbox ma to sens, oczywiście można użyć również isset(),
> nie pamiętam już dokładnie w jakim przypadku,
> ale użycie empty() było wygodniejsze niż isset().

Ja również nie za bardzo potrafiłbym przytoczyć większą wygodę użycia 
"empty". Funkcja isset() w stosunku do badania checkboxów chyba jest 
jedyną sensowną. Jeśli włączysz checkbox o value=0, to empty() pokaże, 
że jest wyłączony.

> a empty() powinno być szybsze.

Szybsze? Przy zastosowaniu jakie podałeś? Nawet jeśli hipotetycznie tak 
jest i polecenie wykona się w 0.05ms zamiast 0.1ms to jakie to ma 
znaczenie dla validacji formularzy?

-- 
Pozdrawiam,
Marek