czesc,
potrzebuje nazwe klasy wywolujacej (czyli get_called_class) tyle ze bez namespace (w php 5.3.x).

rozwiazalem to :

[PHP] pobierz, plaintext 
$cn = explode('\\',get_called_class());
$className = array_pop($cn);
[PHP] pobierz, plaintext 

niby dziala, ale zastanawiam sie czy mozna to inaczej ugryzc, to rozwiazanie wydaje mi sie 'malo eleganckie'...

pozdrawiam,
jacek.

oki, chyba tak by trzeba:

[PHP] pobierz, plaintext 
        $function = new \ReflectionClass(get_called_class());
        $className = $function->getShortName();
[PHP] pobierz, plaintext 

mozna zaorac temat.
j.

Jeżeli już mowa o eleganckości, to wiedz, że jeżeli w ogóle potrzebna Ci ta nazwa, to najprawdopodobniej masz tam coś źle zaprojektowane.

mhmmm...
raczej za szybko wyciagasz wnioski, zwlaszcza ze masz zbyt malo danych ku temu.

najzwyczajniej w swiecie nie korzystam z zadnego frameworka (zbyt specyficzny projekt)
tutaj konkretnie potrzebuje zaczytac ustawienia konfiguracyjne dla danego polecenia.

jesli znasz lepszy sposob na automatyczne zaladowanie parametrow konfiguracji dla danego polecenia - to z checia wyslucham.

j.

edit : literowka

Nie bez powodu napisałem "najprawdopodobniej".
Musiałbyś podać więcej informacji n/t tego co tam robisz, a raczej co docelowo chcesz osiągnąć, bo w tej chwili nie da się nic konkretnego polecić. Musisz też objaśnić co rozumiesz przez "polecenie".

budujemy api.
po stronie serwera - po odebraniu polecenia, ładuję odpowiednia klasę i sprawdzam poprawność wejściowych parametrów wg konfiguracji to tak w mega skrócie.

to zresztą nie ma większego znaczenia - jak napisałem, nie korzystam z żadnego frameworka, więc wszystko piszemy sami. tutaj - jest to nam potrzebne do automatycznego zaczytywania konfiguracji (dlatego potrzebuję nazwy klasy)

tak czy inaczej - nie zagłębiając się zbytnio w szczegóły - potrzebowałem powyższego rozwiązania.

j.

To czy korzystacie z jakiegoś ogólnodostępnego FW czy nie nie ma tutaj nic do rzeczy.
Ot, po prostu z opisu jaki podałeś wynika, że raczej nie ma tam potrzeby na potworki w postaci metod statycznych o get_called_class nie wspominając. Wykorzystanie normalnych obiektów zamiast metod statycznych niemal zawsze niesie za sobą same korzyści.

Wstrzyknięcie konfiguracji w postaci osobnego obiektu?

wszystko w php da sie zrobic na kilka sposobow, takze taki sposob jak podajesz, ale to juz raczej o krok dalej.

tu, do czego to potrzebuje to krok wczesniej : wydobyc odpowiednia czesc konfiguracji z pliku.

pewnie dalo by sie to przebudowac w odpowiedni sposob, i owa nazwe przekazywac w parametrach, ale czy to bylo by lepszym rozwiazaniem? w moim odczuciu - nie.

byc moze nie mam uprzedzen do 'potworkow statycznych', dla mnie sie liczy by kod dzialal efektywnie, przy minimum zabawy.
wstrzykiwanie kodu w tym konkretnym przykladzie wg mojej oceny bylby przerostem formy nad trescia.
poza tym, to co teraz budujemy - prawdopodobnie bedzie dzialac ladnych kilka lat, wymagamy wiec wysokiej czytelnosci kodu, a wstrzykiwanie - takim mi sie nie wydaje.

j.

Teraz tu już na pewno trzeba trochę pomyśleć nad prawidłową architekturą. Kod będzie przez te lata ewoluować, będzie musiał zostać pokryty testami jednostkowymi (a te bardzo nie lubią czegokolwiek statycznego; w ogóle dla OOP - jako paradygmatu - rzeczy statyczne są niezbyt naturalne i wygodne w pracy).

Czasami warto chwilę pomyśleć nad projektowanym kodem, by o tym że jest do bani nie doswiedzieć się gdy już będzie działać w środowisku produkcyjnym.

Mógłbyś napisać o jakiej konfiguracji tutaj mowa, czym ona jest/jak wygląda i dlaczego już teraz potrzebny jest hack w postaci get_called_class() i LSB? Jeżeli podałbyś również docelowe API dla API (czyli w jaki sposób będzie się z niego korzystać) może dałoby się zaproponować inne (w mojej opnii lepsze, bo pozbawione hacków) rozwiązanie.

za dużo by o tym wszystkim pisać.
mogę powiedzieć ze sprawę naprawdę dobrze przedyskutowaliśmy w zespole, a mamy już doświadczenia w budowie api (choć zawsze w nowym projekcie jest coś nowego;) )

testy jednostkowe? zrezygnowaliśmy z nich na rzecz własnego narzędzia.
zadaliśmy sobie pytanie co tak naprawdę nas interesuje.
wyszło nam ze: otrzymany zwrot względem wysłanych parametrów. i właśnie to jest tutaj badane.
np. testy jednostkowe nie wyłapią, czy ktoś zostawił jakiś śmieć w kodzie (np. echo, print_r, etc) my mamy to od ręki.
dodatkowym atutem jest czas, jaki zyskujemy na nie pisaniu unit testow( które i tak nie wystrzegają się błędów logicznych) testy budujemy automatycznie na podstawie pliku konf.
monitorujemy takze czas odpowiedzi serwera, jeśli przekroczymy ustalona wartość - szukamy przyczyn/rozwiazan.

na dłuższą metę - sprawdza się to o wiele lepiej. mamy elastyczne narzędzie, które sprawdza czy to co zmieniliśmy/zrobiliśmy odpowiada naszym założeniom, w razie potrzeby wskazuje miejsce w którym api nie przeszło testów, a nie jest upierdliwe jak unit testy.
decyzja odnosnie przyjecia metody testowania - tez nie byla ad hoc podejmowana, rozwazylismy za i przeciw, i wybralismy najlepsze dla nas rozwiazanie.


komunikacja - na chwile obecną komunikacja po sockecie, w przyszłości byc moze socket + REST, to jeszcze jest do przetestowania/zadecydowania.

format pliku konfiguracji to array (podobnie jak np zend2).

kawalek kodu o ktorym dyskutujemy to:

[PHP] pobierz, plaintext 
$function = new \ReflectionClass(get_called_class());
$className = $function->getShortName();
$this->_paramDefault = $this->_config->API->command->{$className};
[PHP] pobierz, plaintext 

chyba wystarczajaco jasno dalem odpowiedz ;]

j.

Generalnie przy użyciu testów jednostkowych m.in. właśnie to można sprawdzić, ale nie to jest tutaj istotne. Zresztą nic nie stoi na przeszkodzie by używać i jednego i drugiego tam gdzie sprawdzają się najlepiej.

Z tych urywków kodu wygląda na to, że korzystasz z metod statycznych do obsługi tych poleceń. Dlaczego nie użyjesz normalnego obiektu, któremu konfiguracji nie przekażesz w konstruktorze? W końcu na etapie tworzenia obiektu znasz jego nazwę, tak więc będzie można bezproblemowo odczytać konfigurację dla niego. Dzięki temu pozbędziesz się tzw. "z dupy" zależności wewnątrz klasy, co pozwoli na zdecydowanie łatwiejsze testowanie (nie tylko przy testach jednostkowych) jak i ewentualną (tu niemal pewną) dalszą rozbudowę kodu.

https://www.google.pl/search?aq=2&oq=wh...methods+are+bad
https://www.google.pl/search?aq=2&oq=wh...riables+are+bad