Wpis z mikrobloga

@JackBauer: Tak #!$%@?. Jeżeli nie potrafi prównać dwóch stringów to jest #!$%@?. #!$%@? w #!$%@?. Nie wiem czy wiecie, ale === porównuje także typy, więc nawet == powinien zwrócić false, jako że porównywane są stringi zamknięte w "". Jeżeli PHP podczas porównania stringów robi z nich w locie integery , hexy czy #!$%@? wie co po mimo użytych "", to nie jest to właściwość tego języka ale jego #!$%@?.
nie zepsuli porównywania


@nvll: No widzisz, ale Ci od ścisłych języków będą twierdzić, że w luźnych zepsuto porównania jako takie (bo jak to może być, że "" == 0?).

To co jest "feature'em", a co jest błędem jest zależne od celowości i zastosowania. PHP zachowuje się tak, a nie inaczej celowo („specjalnie”, a nie przez „przypadek” czy „błąd”). I ma to też zastosowanie dla każdego kto jest fanem automatycznych konwersji
@nvll: W różnych językach są różne mankamenty i feature'y, grunt to żeby być świadomym mechanizmów. To co widzisz wyżej to nie jest porównywanie stringów tylko dwóch liczb w notacji naukowej, jeżeli coś ci to mówi.
Już w JS ma to więcej sensu, bo tam język po prostu sobie konwertuje lewą i prawą stronę do jednego typu i go porównuje.


@nvll: Przecież tak działa każdy język, po prostu fizycznie nie da się porównać różnych typów, zawsze muszą być skonwertowane do jednakowego. W PHP jest po prostu mechanizm przedstawiania liczb w notacji naukowej i akurat tylko w tym przypadku, jeżeli faktycznie chcesz porównać to jako ciągi znaków, musisz
@nvll: Ale tutaj nie masz porównania różnych typów, tylko takich samych - w tym przypadku liczb. Jakbyś to przyrównał do zwykłego stringa nie korzystając z cechy PHP z notacją naukową, to będzie zwrócony fałsz, mimo, że jakbyś oba stringi najpierw przekonwertował na liczby to oba zwrócą 0.

Po prostu taki feature z notacją naukową ma PHP, to jest już sprawa dyskusyjna, czy przydatny, czy nie. Autor wpisu o tym nie wiedział