On 2014-03-27, g...@g...com <g...@g...com> wrote:
> 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?

Tak z piętnaście lat temu, kiedy Python zaczął dobrze zdobywać
popularność.

>> > 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?

O złożoności czasowej? Ja nie chcę pisać systemu czasu rzeczywistego, ja
chcę wiedzieć że system nie klęknie przy wzroście ilości danych.

> 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)

...z dokładnością do tego, że nie można, bo to nie jest normalna
tablica, a nigdzie nie ma deklaracji, że tak to będzie się zachowywać.

>> >> >> 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

Jeszcze lepiej, każesz mi pilnie śleldzić wnętrzności! Może zakończmy tę
dyskusję, bo o ile jestem tylko sysadminem, to to, co mi właśnie radzisz
o PHP kłóci się straszliwe ze wszystkim, co wiem o pisaniu softu,
a nawet ze zwyczajnym zdrowym rozsądkiem.

>> >> >> 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".

Który z kluczy jest tym w "połowie tablicy"? I co to znaczy "zachowują
porządek wprowadzania"? Jak wprowadzę klucze 9, 8, 7, to będę miał
iterację w tej właśnie kolejności? (Co jest niedorzeczne, bo dla *tablicy*
powinna być rosnąca.) A może w kolejności 7, 8, 9? (Co jest
niedorzeczne, bo klucze-stringi są traktowane inaczej, zgodnie z tym co
mówisz.) W którą stronę się nie obrócić, sytuacja do dupy, bo
w pierwszym wyborze (mieszanie tablic z haszem) ktoś zj***ł sprawę.

> Jezeli nie masz potrzeby robic z tego
> uzytku, to mozesz ignorowac kwestie porzadku w haszach.

Ale to już dawno nie jest standardowy hasz, skoro zapamiętuje kolejność
wprowadzania kluczy. Z samego tego tytułu nie mogę nic powiedzieć
o złożoności czasowej operacji.

>> > 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.

Sam wyciągnąłeś kwestie implementacyjne. Aktualnie sprawa wygląda tak,
że PHP ssie jak odkurzacz.

>> > 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.

Jak to nikt? Dużo tych, którzy znają cokolwiek więcej niż sam PHP.
To nie jest "nikt".

> Jezeli ktos wie, jak korzystac z haszow, poradzi osobie z tablicami PHP.
> Jezeli ktos wie, jak korzystac z tablic, tez sobie poradzi.

Nie ma "sobie poradzić". Ma się nie potykać *niepotrzebnie* o głupoty.

--
Secunia non olet.
Stanislaw Klekot