Jak najprościej sprawdzić nazwę instancji danej klasy bez dodawania żadnych parametrów podczas jej tworzenia, czy później.

class modul{

function nazwa_instancji() {
return [tu niech bedzie 'modul_a', albo 'modul_b', itp...];
}

}

$modul_a = new modul();
$modul_b = new modul();
$modul_c = new modul();

Potrzebna jest mi w mechanizmie klasy informacja jaki modul wykonuje obecnie jakieś działanie...

Nie ma czegoś takiego. Poza tym po co Ci to?

Bo zrobiłem mechanizm, który dogrywa tylko to co jest potrzebne (bardzo elementarnie) i często pewne wspólne elementy (np. parentsy) wykonują różne rzeczy w zależności od tego gdzie zostały uruchomione. Jeśli np. wywołanie idzie ze zmiennej $modul_x, potrzebuję znać ścieżkę do "x", a gdy np. $moduł_graph, wtedy jest inna ścieżka, mimo, że bazują na tych samych parentsach. A to po to, żeby robić jak najmniej a wszystko było wywoływane w ten sam sposób, np. x('graph')->draw->something, x('edit')->costam...

Więc w modułach (nie wiem czy to nowe klasy czy nie) zmieniaj pewne parametry, które definiują to co potrzebujesz.
Podany przez Ciebie pomysł jest najgorszym z możliwych

OT: Co to do cholery są "parentsy"?

o to chodzi: ?
http://www.electrictoolbox.com/php-get-cla...ent-class-name/

Chodzi raczej o nazwę zmiennej, do której on to zapisał.

iksigrek -> nie zrobisz czegoś takiego, ponieważ nazwa zmiennej, a wartość przechowywana w tej zmiennej to dwie całkowicie różne rzeczy. Zwłaszcza, jeśli mówimy o obiektach, gdzie obiekt, a wartość zmiennej to także dwie całkowicie różne rzeczy.

wookieb: Co masz na myśli ?

To nowe instancje tworzone na bazie pewnych charakterystycznych cech opisanych w kilku(nastu) klasach.

Crozin: potocznie na "parent".

IceManSpy: nie mam na myśli sprawdzenia klasy na jakiej bazuje instancja, ale 'jakby' (albo konkretnie, choć to prawdopodobnie niemożliwe) nazwy zmiennej przechowującej instancje danej klasy. To mi sporo ułatwia, bo raz utrzymany schemat jest stosowany wszędzie, tylko czasem potrzebuję, by klasa wiedziała jakiej zmiennej użyłem dla rozpoznania co ma robić i jakie elementy dalej ma ew. ładować. To raczej nie jest standardowy sposób pisania kodu, ale mi póki co bardzo odpowiada ; )

Zyx: no właśnie. W tym kłopot. Było by na miejscu coś w stulu debug_backtrace(), tylko, że dla klasy. Niestety za bardzo nie mam pomysłu w tej chwili jak przeskoczyć to, żeby definicja powiązała "w dół" do informacji na temat danych jakie ją reprezentują (czyli po prostu zmiennej). W tej chwili używam swego rodzaju routera, który sobie z tym radzi, ale chcę się pozbyć parametrów "wnioskowanych" na podstawie nazwy użytej w x(NAZWA)->, a przekazywanych do konstruktora (mam tam m.in. identyfikator modułu, czy ścieżkę w jakiej znajduje się główny plik modułu, od którego potem idę względnie z dalszymi poszukiwaniami plików, czy klas tworzących kolejne, wewnętrzne obiekty. Wszystko natomiast po to by z dowolnego miejsca wywoływać dowolne rzeczy, bez martwienia się co, skąd, czy już było, czy trzeba załadować - czy nie itp.. Ogólnie w ten sposób stworzyłem sobie coś na wzór mocno elementarnych, "kaskadowych singletonów", ładujących jeśli potrzeba coś, a jeśli już to jest - to po prostu z tego korzystających. Zależało mi też na czymś prostym w użyciu, możliwym do wywołania z miejsca gdzie mi się tylko spodoba (z poza instancji, ze statików, z wnętrza samego siebie itd.., przy czym sposób wywoływania zawsze jest taki sam, np.: x->helper->taki_a_taki, albo x->cmd->cos_tam. Nie jest to natomiast jeden obiekt root i drzewo, bo potrzebuję różnych funkcjonalności, a gdybym zrobił roota + gałęzie - nie pozwalało by mi na to i musiał bym przewidzieć wiele scenariuszy (a po co sobie głowę zawracać ) Prawda że wygodne ? W sam raz dla leniwych i takich co nie chcą pamiętać czy już wykonali jakąś operację kilkaset linii wyżej, czy nie (samo sprawdzi co trzeba zrobić i to zrobi jeśli uzna, że musi)... Mam nadzieję, że nie zamieszałem za bardzo.

Podsumowując i w skrócie (jak nie chce wam się czytać tego na górze): Potrzebuję jakiegoś triku*, by dowiedzieć się w użytej już klasie jaka obecnie zmienna ją wykorzystuje.

*Triku - bo bezpośrednio to chyba tak samo nierealne, jak nierealne by papierowa książka mogła dowiedzieć się kto ją właśnie czyta i wstawić jego imię zamiast imienia głównego bohatera (ale odwrotnie - bez problemu - jak np z get_class() )

wydaje mi sie ze to co robisz jest chore ale z drugiej strony.. kazde nowe podejscie jest ciekawe
jak bym to rozwiazal przeleceniem po odpowiednich galeziach
get_defined_vars()
i sprawdzeniem "gdzie siedzi moja wlasna instancja"

yevaud, trzeba życiu nadać odrobinę smaku, a nie tylko szara owsianka co rano ; )

Szczerze powiedziawszy, to co próbujesz zrobić jest... chore, złe i w ogóle dzieci w Afryce przez to zginą... Od razu zaznaczę, że nie do końca rozumiem co chcesz tak naprawdę osiągnąć, ale z tego co widzę próbujesz oprzeć działanie systemu na nazwie zmiennej. Dlaczego to jest złe?

1. Nawet jeżeli uda Ci się takie coś osiągnąć ogarniesz to prawdopodobnie tylko Ty - sposób działania będzie tak nienaturalny i sprzeczny z jakimikolwiek zasadami programowania, że bez głębokiej analizy ciężko będzie się połapać w tym co robisz.
2. Prawdopodobieństwo wystąpienia błędu jest ogromne - nazwy zmiennych w przeciwieństwie do nazw klas czy "usług" zmienia się relatywnie często, zmiana nazwy w jednym miejscu niesie za sobą konieczność zrobienia tego w innych.
3. Nie będziesz miał do dyspozycji żadnych narzędzi, które ułatwiałyby Ci pracę z tym - żaden debugger/IDE/whatever nie traktuje jakoś szczególnie samych nazw zmiennych

Swoją drogą mógłbyś rzucić jakimś kodem, który pokazywałby co chcesz uzyskać - swoisty interfejs/sposób użycia Twojego rozwiązania (sama implementacja jest nieważna). Tak chyba będzie nam łatwiej pojąć co chcesz zrobić.

A to widziałeś: http://bytes.com/topic/php/answers/11585-h...ance-its-inside

Na dobrą sprawę to tylko potwierdzenie tego, że to głupi pomysł. Ktoś tam słusznie zauważył, że w przypadku, gdy więcej zmiennych wskazuje na ten sam obiekt będzie problem z ustaleniem nazwy:

[PHP] pobierz, plaintext 
<?php
 
$obj = new MyObject();
$a1 =& $obj;
$a2 =& $obj;
$a3 =& $a1;
 
echo $obj->getName(); // Co ma zwrócić? obj, a1, a2, a3? A może tablicę wszystkich?
[PHP] pobierz, plaintext 

Co więcej sposób, który miał niby rozwiązywać problem nie robi tego:

[PHP] pobierz, plaintext 
<?php
 
class TestClass {
        public $setMe;
        public $abc = 'def';
}
 
$a = new TestClass();
$b = new TestClass();
 
echo serialize($a) . PHP_EOL;
echo serialize($b) . PHP_EOL;
[PHP] pobierz, plaintext 

Zserializowane obiekty będą identyczne => będą miały ten sam hash => nie będą rozróżnialne.

@iksigrek - pomijając fakt że nie bardzo wiem do czego chcesz to zastosować - robiłem niedawno podobny risercz (miałem obiekt który konstruował funkcję odwołującą się do niego). Więc - doszłem do dwóch rozwiązań:

1. Jeśli instancja jest zmienną globalną to wystarczy że w konstruktorze przelecisz całą tablicę zmiennych porównując je ściśle do siebie - pierwsze znalezione dopasowanie jest twoim obiektem
2. Tworzysz jakąś klasę rejestrującą instancje - każdy obiekt którym jesteś zainteresowany tworzy tam dodatkową referencję

Co do twojej metody - ta funkcja nie może wyglądać tak?

[PHP] pobierz, plaintext 
function x($name,array $vars=NULL) {
 //obrabiam nazwę klasy + zmienne konstruktora $vars
// konstruuję nazwę klasy którą chcę wywołać + właściwe zmienne przekazywane do konstruktora
 return new $my_class($moje_zmienne_dla_tego_obiektu);
}
[PHP] pobierz, plaintext 

Słuchajcie, ogólnie rzecz ujmując, dużo zamieszania się zrobiło (i fajnie w sumie ), a mi tak naprawdę chodziło o to by pobrać tę nazwę zmiennej. Jednak nie chce tworzyć systemu BAZUJĄCEGO na tym. To był po prostu jakby zabieg kosmetyczny w moim wypadku, bo systemik już jest i jak dla mnie - całkiem wygodnie działa everth, to co napisałeś o post wyżej - właśnie tak mniej więcej robię to obecnie. funkcja x(cos)->innegoCos zwraca returnem dane klasy statycznej, np. return statyczna::fragment(cos). Sama klasa statyczna posiada natomiast wszystkie mechanizmy lapiace co i jak i zanim zwróci mi jakiś obiekt - sprawdza co to, gdzie to, skąd to - i tworząc go przekazuje mu odpowiednie parametry na podstawie tych danych. Kosmetyka natomiast miała to być dlatego, że chciałem się tych parametrów jakoś pozbyć, żeby "oczyścić" konstruktory. No ale jak się nie da to się nie da.

Można natomiast pogadać o kwestii samego systemu, bo myślę, że to ciekawy temat - o tyle, że każdy by chciał mieć frameworka, przy którym jak najmniej się narobi i niewiele wbrew pozorom trzeba pamiętać. Oczywiście wątek pewnie nie raz był poruszany, ale co tam... Najwyżej ktoś tu pomajstruje ; )

u mnie jest tak, jak pisałem na górze - bez względu na to gdzie jestem w systemie - jak to "gdzieś" jest podczepiane pod główny index - to pisze się zawsze i wszędzie x(MODUL)->obiektowa->metoda->... albo x(MODUL)->daneJakiegosTypu['...']. Gdy coś jest niezaładowane, jest automatycznie ładowane w jak najprecyzyjniejszym zakresie (Bo po co ładować całą wielką klasę i tworzyć spory obiekt, skoro w danym przebiegu skryptu wykorzystam tylko 20% - 30%... Wszystko co zostało raz załadowane - to singletony, więc nie mnożą mi się zbędne kawałki i obiekty. Wszystko wyświetla się na zasadzie pól i stref. Pole może siedzieć w dowolnym miejscu strony, wystarczy wpisać w pliku np. x(MODUL)->field(name). Pole może zawierać różne strefy, w zależności od tego co potrzeba. Np. pole x(ART)->field(content) zmienia zawartość w zależności od tego jaki id arta jest wyświetlany, a pole x(USER)->field(login) zawiera formularz logowania, albo info o zalogowanym użytkowniku. Jak coś potrzeba zmienić to robię to tak: x(MODUL)->field_change(...) itd... tak więc co by się nie działo, zawsze i wszędzie tak samo postępuje. Nie chcę mieć obiektu globalnego (stąd static), bo łatwo go podejrzeć. Co o tym myślicie ? Można by to rozwiązać jakoś prościej ?