W dniu czwartek, 27 marca 2014 02:28:31 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> On 2014-03-26, g...@g...com <g...@g...com> wrote:
>
> > Historycznie. Wiele z tych niedostatkow zostalo juz poprawionych,
>
> ...w ciągu ostatnich czterech-sześciu lat, czyli już dawno po
> terminie...

A jaki byl termin?

> >> >> > Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
> >> >> > potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.
> >> >>
> >> >> ...gwarancje czasowe?
> >> >
> >> > Jezeli piszesz "time-critical application", to zgadzam sie, ze PHP
> >> > to zly wybor. Podobnie jak wybor wiekszosci innych jezykow dynamicznych
> >> > oraz wszystkich jezykow z garbage collectorem.
> >>
> >> Ależ nie chodzi o aplikacje krytyczne czasowo. Chodzi o bardziej
> >> elementarną rzecz: przewidywalne zachowanie w przypadku wzrostu ilości
> >> danych. Nie chcę żeby nagle się okazało, że mój program *wyglądający*
> >> jak mogący sobie poradzić z danymi osiem razy większymi w czasie jedynie
> >> osiem razy dłuższym kończy pracę w czasie czterysta razy dłuższym.
> >
> > Takich gwarancji nie daje nawet C.
> > A PHP pod tym wzgledem nigdy mnie nie zaskoczyl, chociaz robilem
> > z nim naprawde dziwne rzeczy.
>
> W C wiadomo, że dostęp do elementu w tablicy ma złożoność O(1). W PHP
> nie wiadomo, bo przy tej mieszance nie-wiadomo-jakiej-mapy (hasz
> z porządkiem to *nie jest* standardowa implementacja hasza) i tablicy
> nie jestem w stanie powiedzieć, że złożoność jest O(F(n)).

To mowimy o czasie, czy o zlozonosci?
Jezeli uruchamiasz cos na systemie ze stronicowaniem pamieci,
to tracisz wszelkie gwarancje czasowe (chyba ze korzystasz z jakichs
watkow czasu rzeczywistego). Na potrzeby praktyczne mozna uznac,
ze w PHP czas dostepu do tablicy jest rzedu O(1)

> >> >> A pomieszane głupio, bo nie potrzebuję indeksować tablicy stringami.
> >> >> Potrzebuję mieć gwarancję dostępu w czasie O(1). Jak będę potrzebował
> >> >> indeksowanie stringami, to sobie użyję hasza i będę wiedział, jakie on
> >> >> daje gwarancje na operacje.
> >> >
> >> > Jezeli nie potrzebujesz indeksowac tablicy stringami, to nie musisz
> >> > tego robic. Jezeli korzysasz ze spojnych kluczy numerycznych od 0, to
> >> > bedziesz mial normalna tablice numeryczna z dostepem w czasie O(1)
> >>
> >> A gdzie są te gwarancje zapisane? W dokumentacji nie pamiętam żeby były.
> >>
> >> Czy tak tylko zmyślasz na temat gwarancji złożoności w PHP?
> >
> > Faktycznie w dokumentacji tego nie ma, i nie sadze, zeby PHP dawal
> > gwarancje. (Jak stanowi licencja, THIS SOFTWARE IS PROVIDED
> > BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR
> > IMPLIED WARRANTIES). Ale z tego co czytalem, to w praktyce
> > tak wlasnie jest implementowane, co szybki risercz wydaje
> > sie potwierdzac:
>
> > http://stackoverflow.com/questions/2350361/how-is-th
e-php-array-implemented-on-the-c-level
>
> Czyli chcesz powiedzieć, że mam się oprzeć o nieudokumentowane
> zachowanie, które może się zmienić między patchlevelami? Naprawdę tak
> uważasz? W swoim własnym kodzie tak robisz?

To zalezy, jaki problem chce rozwiazac. Ale jezeli tak niepokoi Cie kwestia
gwarancji, to:
1) zrodla PHPa sa dostepne, mozna sobie poczytac
2) nie musisz robic update'u do nowszej wersji, jezeli mialyby z tego
wynikac jakies problemy

> >> >> Tablice w PHP to jakby ktoś wymieszał B-drzewa z wyrażeniami
> >> >> regularnymi. Można to trzymać razem, ale kto przy zdrowych zmysłach
> >> >> potrzebuje takiej konstrukcji?
> >> >
> >> > Nie wiem, jaki jest zwiazek B-drzew z wyrazeniami regularnymi.
> >> > Tablice php-owe opieraja sie na spostrzeniu, ze sekwencje rowniez
> >> > stanowia forme asocjacji.
> >>
> >> Co nie znaczy, że to dobry pomysł mieszać haszmapy z tablicami, bo te
> >> struktury mają różne zastosowanie, różną budowę i różnie się zachowują
> >> przy większości operacji.
> >
> > Maja taki sam interfejs.
>
> Nie. W haszu nie ma pojęcia pojęcia "połowa tablicy". W haszu nie ma
> pojęcia "element 2*n+1", w każdym razie nie bez dziwnego, sztucznego
> traktowania kontenera przez programistę ("umówmy się, że nie będę
> robić X").

Tablice PHP zachowuja porzadek wprowadzania, wiec jest w nich
pojecie "polowa tablicy". Jezeli nie masz potrzeby robic z tego
uzytku, to mozesz ignorowac kwestie porzadku w haszach.

> > Bystry kompilator moglby sam wpasc na to, kiedy uzyc jakiej struktury
> > danych.
>
>
> W PHP nie ma bystrego kompilatora (czy tam parsera). W PHP jest
> interpreter, który jest tak głupi, że dla niego 0x0+2 = 4.
> Interpreter PHP nawet nie konstruuje drzewa wyprowadzenia, tylko
> uruchamia kod od razu w ramach akcji semantycznych.

To prawda. Ale to kwestia implementacji, a nie semantyki.
(Choc akurat jezeli idzie o kwestie semantyki, to to dopiero
jest bajzel).

> > A z perspektywy uzytkownika nie musi miec znaczenia, czy uzywa
> > drzewa, wektora czy haszmapy, i jezeli ktos moze tutaj cos pojeciowo
> > namieszac, to tylko sam uzytkownik.
>
> Dlaczego chcesz *zmuszać* użytkownika do stałego uważania jeszcze w tym
> miejscu? W PHP jest wystarczająco dużo miejsc gdzie można się potknąć.
> Dlaczego dokładać jeszcze to jedno? Bo na pewno nie dla wygody (w innych
> językach hasz i tablica są rozdzielone i *nikt* nie narzeka).

W PHPie nie sa rozdzielone, i tez nikt nie narzeka.
Jezeli ktos wie, jak korzystac z haszow, poradzi osobie z tablicami PHP.
Jezeli ktos wie, jak korzystac z tablic, tez sobie poradzi.