Piszę sobie teraz coś w stylu edytora konfiguracji, który bazuje na czystym źródle.

[PHP] pobierz, plaintext 
<?php
array('k1'=>'v1', 'k2'=>array('v2k1'=>'v2v1', 'v2k2'=>null))
?>
[PHP] pobierz, plaintext 

I na tego typu kawałkach kodu grzęznę. Wszystko by było ok, gdyby nie było subtablic. Traktować tego eval" title="Zobacz w manualu PHP" target="_manualem nie chcę, nie mam pomysłu na to, aby zrobić z tego uzyteczną tablicę, np:



Myślałem, żeby przetworzyć to jak XML, ale tam są przecież nazwy znaczników na początku i na końcu bloku, a tu tylko nawias.
Przyszedł mi jeszcze do głowy pomysł, żeby robić stosy przez nawiasy otwierające/kończące, ale to IMHO niezbyt dobre rozwiązanie, bo wystarczy dać (2+2) jako wartość i już się sytuacja komplikuje...

Ma ktoś jakieś pomysły? Ślęczę nad tym już ładny kawałek czasu i nijak nie mogę tego rozgryźć...

Nie wiem czy rozumiem problem. Ja zrobiłbym to rekurencyjnie na zasadzie preg_match_callback(). To co pasuje do wzorca, zapisujemy w tymczasowej tabeli i podmieniamy na coś w stylu !!1!!, gdzie liczba w środku to klucz tablicy tymczasowej z elementem oryginalnym. Jako dopasowanie bierzesz tylko zmienną lub array(!!x!!); (oczywiście te !!x!! możesz tymczasowo wycinać, lub szukać dopasowania do array\(!![0-9]*!!\) i też podmieniać) w sensie zawartość musi być sparsowana wcześniej. Jak już masz to rozbite na elementy pierwsze to już sobie sprawdzasz co jest co.
Pozdrawiam!

Też mi coś takiego po głowie chodziło, ale załóżmy taki przypadek:

[PHP] pobierz, plaintext 
<?php
array('asdas', 'sdqwe', 'sde', time(), STALA_I_SIADLA)
?>
[PHP] pobierz, plaintext 

i już się sytuacja komplikuje, bo gdyby jako "klamr" prega użyć array( i ), to wtedy "łapie" za nie ten nawias, co trzeba... ;/

może to Ci coś pomoże: bedkowski.pl

A może, tak dla odmiany, skorzystaj z Yaml? http://www.yaml.org/

A tu przykład możliwości: http://www.symfony-project.org/book/1_0/01...ng-Symfony#YAML

dosc pokretne
gdybys napisal jasniej co chcesz osiagnac z jakiego typu konfiguracji to moze..

a jesli chodzi o "to wtedy "łapie" za nie ten nawias, co trzeba... ;/"
zainteresuje sie zachlannoscia wyrazen regularnych

Wcale nie bo pattern złapie tylko (pomijając zmienne) array(!!13!!) czyli cała zawartość nawiasu musi być wcześniej sparsowana. jeżeli wygląda to tak:

Najpierw podmieni " a => 1" na !!1!! i mamy:


Pozdrawiam

http://www.zyxist.com/pokaz.php/formaty_danych_benchmark

...
Z plikami ini na razie się wstrzymuję.


Ok, napiszę najprościej, jak tylko potrafię - ze względu na wydajność, chcę trzymać konfigurację bezpośrednio w kodzie, w tablicach. Dlaczego? Otóż, zależy mi na kompromisie między wydajnością a wygodą w przypadku ręcznej edycji, jeśli by to było konieczne. Docelowo, pliki mają być także edytowalne za pomocą inspektora napisanego w PHP. Rozwiązania SGML-owe odpadają z powodu wydajności, zserializowane tablice raczej ciężko jest bezpośrednio edytować, w plikach ini trochę ciężko z wielowymiarowością (choć wcale nie twierdzę, że jest to niemożliwe) i trzeba kombinować z wyrażeniami/stałymi/etc. Bardzo zależy mi na w miarę czytelnym rozwiązaniu, ale jednocześnie takim, które będzie najwydajniejsze. Więc klasyczne tablice są IMHO najbardziej kompromisowym rozwiązaniem tym bardziej, że mogę sobie plik przepuścić przez osobną instancję parsera, aby go ewentualnie zwalidować.

No i do czego piję - czasem zajdzie potrzeba zmodyfikowania jakiegoś pliku konfiguracyjnego "przez automat" i tu zaczynają się schody. Owszem, mogę wszystko potraktować evalem albo po prostu zainclude'ować, ale wtedy do widzenia mówię nazwom stałych/funkcji/wyrażeń użytych do pozyskania wartości.

Chcę tak jakby evalować ten kod (tylko jako strukturę) zachowując deklarację wartości (oprócz array, bo one odpowiadają za strukturę).


Cały czas próbuję coś modzić; założyłem ten temat po n-dziesięciu podejściach... Łącznie z przeglądaniem źródeł samego interpretera (sic!)...

ayeo, a mógłbyś pokazać przykładowy sposób zaimplementowania? W znacznikowych, to no problem, bo idzie po znacznikach, a tu jakoś nie mam już pomysłu...

W czym problem z wydajnoscia ?
Mam 1 typ configu w XML z wlasnym parserem w obie strony, czyli save i load z pelna edycja przez CMS - wyrazenia regularne oczywiscie, drugi taki sam na *.ini.
Wrazenie wygody trzymania w a'la code jest tylko wrazeniem moim zdaniem.
Regexem wyciagniesz i nazwy zmiennych i dane, wstawisz je w obiekt z nazwami wlasciwosci takimi jak w pliku - czyli dynamicznie tworzonymi, dostepnymi jak uwazasz albo przez prop[name]=val albo prop->name.
Zaleta jest taka, ze ini i xml sa do tego powszechnie stosowane, wiec nauczysz sie czegos uniwersalnego a i modyfikacja nie tylko przez ciebie jest latwiejsza do zrozumienia dla ewentualnego uzytkownika, a parser do kodu bedzie raczej srednio uniwersalny.
Pewnie, ze mozna.

Zamieściłem link do benchmarka poszczególnych sposobów zapisu.

Napisać parser do XML/INI, to nie problem, ale chcę na razie wyczerpać wszystkie możliwe sposoby...

Jeżeli trzymanie danych konfiguracyjnych w postaci czystego PHP nie jest warunkiem koniecznym, to zainteresuj się formatem JSON (http://www.json.org/). Jest znacznie wygodniejszy w użyciu (do tego celu) niż XML - przypomina zserializowaną tablicę, lecz jest prostszy i przyjemniejszy dla oka (co ważne w przypadku ręcznej edycji!).

W PHP >= 5.2.0 masz do dyspozycji f-cje json_encode/json_decode - jeżeli korzystasz ze starszej wersji, możesz skorzystać z PECL-a: http://pecl.php.net/package/json.

Jeżeli pozostaniesz przy czystem PHP-ie, to nie ma sensu unikać eval'a, bo skończysz na napisaniu od zera własnego parsera PHP, który z definicji będzie miał wszystkie te same wady (np. bezpieczeństwo), lecz w przeciwieństwie do parsera Zenda nie będzie miał za sobą kilkunastu lat debugowania i rozwijania przez środowisko open source.

JL

No ok. Zyx pokazał co szybkie co wolne, ale ... przecież wszyscy wiedzą że różnorodne parsowania są wolne. Dlatego też wybierasz sobie format, parsujesz, robisz cache i z głowy problem wydajności.

No to wiadomo, że wszystko jest parsowane - nawet zdania, które wypisujemy. ;P

Cache, cache - ale po co sobie dorabiać więcej roboty, skoro można prościej...?

W sumie, podłubałem, podłubałem, idea Ayeo była najbliższa, także podsunął mi potem kilka sugestii (fakt, na pregach, ale... ;]).

Skończę usprawniać ten kod, co udało mi się już otrzymać i wkleję dla potomnych. ;]

PS. Nie popełniajcie kolejny raz tego samego głupiego błędu, co ja: 3. parametr substr" title="Zobacz w manualu PHP" target="_manual, to length, a nie drugi offset... :S