Załóżmy, że mamy wielowymiarową tablicę, której struktury do końca nie znamy. Korzysta z niej kilka innych obiektów, mogą one wstawiać do tej tablicy wartości pod odpowiednimi indeksami, ale i też je wyciągać (zakładamy, że nigdy nikt sobie na wzajem danych nie nadpisze). Ale ta tablica ma być "zarządzalna" przez osobny obiekt. To znaczy, by pobrać jakąś wartość trzeba użyć metody $object->get('index'), a żeby wstawić $object->set('index', 2). Nigdy nie ma bezpośredniego dostępu do tej tablicy.

Jak wykonać metody pobierania i wstawiania do tablicy, by były możliwie jak najszybsze (operacje na stringach to jakaś masakra w PHP ;/) i żeby można było dostać się do tablicy wgłąb, na przykład: $table['index1']['index2']['index3']?

Wymyśliłem, by na poczekaniu tworzyć funkcję anonimową (create_function), której prześlemy całą tablicę, a w stringu stworzymy już indeks do pobrania:

[PHP] pobierz, plaintext 
$index    = "['".implode("']['", explode('.', $index))."']";
$function = create_function('$array', 'return (isset($array'.$index.') ? $array'.$index.' : null);');
return $function($array);
[PHP] pobierz, plaintext 

I teraz, jeśli chcemy pozyskać jakąś wartość to w parametrze metody podajemy ciąg znaków: 'index1.index2.index3'. Ale nie jest to zbyt szybkie.

Macie może inne pomysły na rozwiązanie tego problemu?

Najprościej, choć niezbyt elegancko, wytłumić błędy:

[PHP] pobierz, plaintext 
$data = array();
$element = @$data['animals']['dog']['name']; // NULL
[PHP] pobierz, plaintext 

A nie możesz spłaszczyć tej tablicy? Co ona zawiera?

Można do tego dojść na kilka sposbów, można używać kropek pomiędzy indexami, a można zrobić to tak:

[PHP] pobierz, plaintext 
<?php
 
class Object
{
    protected $data = array();
 
    public function __construct(array $array = array())
    {
        $this->data = $array;
    }
 
    public function has($name)
    {
        return array_key_exists($name, $this->data);
    }
 
    public function get($name, $default = null)
    {
        if($this->has($name))
        {
            if(is_array($this->data[$name]))
            {
                return new static($this->data[$name]);
            } else
            {
                return $this->data[$name];
            }
        }
 
        return $default;
    }
 
    public function set($name, $value)
    {
        $this->data[$name] = $value;
    }
 
    public function all()
    {
        return $this->data;
    }
} 
 
$obj = new Object();
 
var_dump($obj->get('something'));
 
$obj->set('something', 'some value');
 
var_dump($obj->get('something'));
 
$array = array(
    'key' => 'value',
    'key2' => array(
        'key3' => 'value3',
    )
);
 
$obj2 = new Object($array);
 
var_dump($obj2->get('key2')->get('key3'));
[PHP] pobierz, plaintext 

Do czegoś takiego można jeszcze dodać metodę magiczną i uzyskać trochę "magii":

[PHP] pobierz, plaintext 
<?php
 
class Object
{
    protected $data = array();
 
    public function __construct(array $array = array())
    {
        $this->data = $array;
    }
 
    public function has($name)
    {
        return array_key_exists($name, $this->data);
    }
 
    public function get($name, $default = null)
    {
        if($this->has($name))
        {
            if(is_array($this->data[$name]))
            {
                return new static($this->data[$name]);
            } else
            {
                return $this->data[$name];
            }
        }
 
        return $default;
    }
 
    public function __get($name)
    {
        return $this->get($name);
    }
 
    public function set($name, $value)
    {
        $this->data[$name] = $value;
    }
 
    public function all()
    {
        return $this->data;
    }
} 
 
$obj = new Object();
 
var_dump($obj->something);
 
$obj->set('something', 'some value');
 
var_dump($obj->something);
 
$array = array(
    'key' => 'value',
    'key2' => array(
        'key3' => 'value3',
    )
);
 
$obj2 = new Object($array);
 
var_dump($obj2->key2->key3);
[PHP] pobierz, plaintext 

I nie jest to wcale takie trudne..

Pytanie tylko po co tak kombinować. Moim zdaniem to jest jeden z bardzo niewielu przypadków, gdzie lepiej użyć operatora @. Efekt jest ten sam, tylko PHP wypluje błąd (stłumiony) zamiast sprawdzać "ręcznie" te indeksy. Świat się nie zawali od operatora @.

Widzisz, operator wytłumienia nie powinno się nigdy używać, czasami zachodzi taka potrzeba jak robimy coś na kolanie. Ten operator działa tak że wytłumia błąd, tzn ty go nie widzisz, ale ten błąd się nadal generuje, jak masz jakiegoś handlera, to jest on wywoływany, tyle że jest on "ukryty". Niech teraz takich błędów będzie wytłumione 20 razy, wtedy twój handler jest wywoływany 20 razy. Czyli zużyte zasoby są dużo większe. Dodatkowo kompiler opcode (kto w ogóle nie używa opcachera ?) przechowuje taki kawałek kodu w postaci 2-3 razy obszerniejszej. Jaki sens ma skrócenie kodu do 1 znaku, jeżeli jego wymagania będą takie jakby się użyło funkcji/klasy?

Pozatym autor chciał coś obiektowego, co by sugerował jego pierwszy post..

Też tak uważałem, ale jednak nie warto popadać w skrajność. Jeśli jest używany z głową, to w czym problem? Traktowanie błędu jak jakiegoś kataklizmu jest dziwne. To lepiej kombinować z jakimiś rozwiązaniami typu kropki w indeksach niż po prostu powiedzieć interpreterowi: "jest w porządku, jeśli tu wyrzucisz błąd, bo wiem że będzie chodzić o brak klucza"? Małpa w tym kontekście ma w sobie coś fajnego, tzn.:

[PHP] pobierz, plaintext 
$tablica['klucz1']['klucz2'] // mam nadzieję, że te dane tu są - jeśli nie, to wyrzuć błąd
 
@$tablica['klucz1']['klucz2'] // nie wiem czy te dane tu są czy nie, jak nie ma to w porządku
[PHP] pobierz, plaintext 

Zalecam zdrowy rozsądek zawsze i wszędzie.

Jesteś pewien, że handlery błędów się wywołują przy stłumionych błędach?

Jak najbardziej. I jesli w handlerze nie masz ustawionego, by nie lapal tlumionych, to handler bedzie ci normalnie je obslugiwal. Jesli bedziesz zapisywal do do pliku te bledy to plik bedzie pochl i pochl......

Pytanie tylko kto zapisuje w pliku błędy typu notice. Ja uwielbiam tego typu dyskusje, można poznać różne punkty widzenia. Nie jestem fanatykiem ani jednego, ani drugiego wyjścia. Złotym środkiem może się okazać używanie klasy typu Collection, które mogą oferować wiele przydatnych funkcji nieobecnych domyślnie dla tablic. Tak sobie pomyślałem, że takie skomplikowane i nieobliczalne struktury to już może być trochę za dużo dla tablicy.

Hmm.... moze porządny programista, ktory zdaje sobie sprawe z tego ze jest tylko czlowiekiem i ze moze gdzies popelnic glupi blad, ktorego nie zauwazy?
To prawda, ze akurat w tym przypadku NOTICE to zwykla niechciana popierdulka ale ogolnie bledy NOTICE to cala gama bledow i wbrew pozorom mogą wskazywac na blad, ktory moze miec kolosalne skutki.

Nie trzeba być fanatykiem żadnego rozwiązania. Ale logowanie każdego rodzaju błędów, bo przecież tego błędu w aplikacji nie wyświetlisz jest wymagane, bez względu na to jakie twoje podejście jest. Albo coś robisz i masz nad tym kontrole, albo to żyje swoim życiem. Tak wywoływanie handlera 20 razy jest bardziej optymalne niż prosta klasa.. No raczej nie, bo cały "stack" jest wtedy generowany 20 razy. A do tego mojego "prostego" rozwiązania, mogę kontrolować co będzie mi zwracać dana zmienna, jeżeli dany klucz nie istnieje.

Możesz skorzystać z całkiem przyzwoitego komponentu PropertyAccess z Symfony, ale przede wszystkim powinieneś w ogóle zmienić podejście. Wielowymiarowa tablica, gdzie coś może istnieć bądź nie, czego nawet w pewnym sensie nie chce Ci się sprawdzać... to doprowadzi jedynie do ogromnego bałaganu i niestabilności w działaniu systemu.

Pojawienie się notice'a powinno w zdecydowanej większości przypadków skutkować wywaleniem całego systemu, bo w tym momencie, zachowuje się on w sposób nieprzewidziany.

Trochę OT ale moim zdaniem całe to zadanie nie ma najmniejszego sensu...

Ja to widzę bardziej jako tzw. rejestr w aplikacji - każdy moduł/obiekt może z niego korzystać bo jest dostępny ogólnie. Jeśli z kolei każdy obiekt korzysta tak jak pisał autor czyli nie nadpisując sobie niczego to tym bardziej rejestr się nadaje - każdy obiekt trzyma w nim dane, które sam zmienia - inne mogą odczytywać. Nie widzę sensu w takim udziwnianiu bo nic to nie daje Mogłoby dawać blokowanie edycji ( dana ścieżka dostępna tylko dla określonego obiektu) tylko po co pisać coś od nowa jak mamy takie coś jak ACL...

Sposobów rozwiązania jest MASA - by_ikar podał fajne - tylko po co tworzyć takie dziwne "smoki" i "potwory" jak można użyć takich wzorców jak rejestr albo zbudować własny rejestr w połączeniu z ACL... (choć i to dla mnie już przesada)...

Autor - jak możesz - uzasadnij - czemu akurat tak? Czy może to taki zamysł po prostu?

Ma to być prosta klasa, która będzie czymś na zasadzie pamięci podręcznej ustawień w systemie. Teraz mam wszystko podzielone ładnie na pliki, które są w różnych formatach i w różnych miejscach, ale chciałbym to przyśpieszyć. Wrzucę wszystko do pliku w formacie PHP w formie tablicy i będę tym zarządzał za pomocą klasy. Oczywiście "wrzucę" nie ręcznie, tylko skryptem, w tedy gdy dany plik konfiguracyjny został odświeżony lub gdy jeszcze nie został dodany do globalnego. Chodzi mi po prostu o przyśpieszenie operacji na ustawieniach aplikacji.



EDIT.

Różnica pomiędzy moim pomysłem z funkcją anonimową a pomysłem @by_ikar jest rzędu ok 0.02 sekundy, na 1000 wywołań.

Wywołanie moje:

[PHP] pobierz, plaintext 
$result = $config->get('kernel.framework.session');
[PHP] pobierz, plaintext 

Wywołanie @by_ikar:

[PHP] pobierz, plaintext 
$result = $config->get('kernel')->get('framework')->get('session');
[PHP] pobierz, plaintext 

Zaletą tego pierwszego jest to, że nawet gdy podam jako argument 'kernel.framework', to zwróci mi to tablicę jeśli ona tam jest, a w drugim przypadku zwróci mi obiekt. Musiałbym zastosować dodatkowy drugi argument funkcji, w którym definiowałbym, czy metoda get() ma zwrócić mi obiekt czy samą tablicę (w tym przypadku).

Pytanie, czy przy 1000 wywołań, narzut na poziomie 0.02 sekundy jest możliwy do zaakceptowania? Biorąc pod uwagę to, że troszke lepiej można operować na zwróconych danych.

Nie przejmowałbym się tym.
Co do rozwiązania @by_ikar możesz dodać metodę np. toArray którą wywołasz na końcu łańcucha i gotowe.

Mógłbym, ale co jeśli zwrócona wartość będzie stringiem zamiast obiektem? Wydaje mi się, że drugi parametr, opcjonalny, będzie lepszym wyjściem.

Może być czymkolwiek. Po prostu w metodzie robisz sprawdzanie, czary mary i wypluwasz to co chcesz aby było wyplute.

Kilka rozwiązań:

1. Zacznij od wczytania wielowymiarowej, zwykłej tablicy. Pozwól każdemu z modułów odpowiednio ją przetworzyć (niech każdy z modułów we własnym zakresie martwi się o strukturę danych) po czym spłaszcz całą tablicę wielowymiarową do tablicy jednowymiarowej.
2. Utwórz zestaw odpowiednich klas, których obiekty będą służyć za konfigurację. Innymi słowy pozbądź się kompletnie tablic.
3. Skorzystaj ze wspomnianego już wcześniej przeze mnie komponentu PropertyAccess z Syfmony - o ile wydajnościowo jest akceptowalny.

Napisz też dokładnie jakie problemy/trudności sprawia wykorzystanie "czystej" tablicy. Tzn. w jakim celu koniecznie chcesz posiadać metody ::get() i ::set() - może cały problem w ogóle nie jest warty zachodu?

Jak już pisałem wczesniej. Aplikacja używa kilku plików konfiguracyjnych, które są w różnych miejscach i zapisane różnych typem (PHP, INI). Chcę przerobić to na tablicę PHP i zapisać do pamięci podręcznej do jednego pliku by zaoszczędzić troszkę czasu wykonywania skryptu. Części aplikacji odpowiedzialne za np. bazę danych czy routing, pobierały by ustawienia za pomocą tej właśnie klasy, a ona pobierała by te dane z pliku w pamięci podręcznej i odświeżała w miare zmian w plikach oryginalnych.

Wiem, że to może troszkę nie tak jak powinno być, ale jeśli jest na to inne rozwiązanie to chętnie o tym przeczytam.

Tak,ujednolicić pliki konfiguracyjne