Re: libpurple php binding

yes, it's exactly the thing ... but i need to got exactly the inherited object to use its overloaded methods ... so i need to controll things from within c land ... it might be look so: within php: parent_internal_class => child_php_class => child_overload_parent_methods => child_object within c: event_catched => libpurple => call_libpurple_callback_function => child_object->callOverloadedMethod() so i need exactly the object was created to use it methods within c callbacks On Tuesday 25 December 2007, Alexey Zakhlestin wrote: > I think you are looking for Singleton pattern… > It will allow you to make sure, that there's only one instance. > > in short, you have to do the following: > make constructor "private", and create static method, which calls > constructor and stores static member with created instance or returns > it, if there is one, already > > On 12/25/07, Anatoliy Belsky <thinker@online.de> wrote: > > i've used wrong email address in my last message ... sorry > > > > o, so i'll further modify it to make the thing simple but powerfull. > > > > The DateTime object must come in too. > > > > May be you can suggest me to some idea, how i can catch which object was > > instantiated and which class was inherited from the internal purple > > class. For example if user makes two child classes (or more) and then > > instantiates them ( may be each twice, for the hardness :) ) - something > > like this couldn't work. But i need to know the child class object to run > > its methods as libpurple callbacks. So hm ... this means i must somehow > > monitor all objects are being created. May be you know some extension > > uses this modell? > > > > For example, u can try to start two copies of the pidgin and you'll see - > > one of them will disconnect. However, i cann't predict the behavior of > > the libpurple in such situation. > > > > From the other side with the callback class i'm simply saving the > > callback object to the module globals and if some other purple object > > instantiates the internal callback is being simply overwritten with the > > actually. So i don't need to take care about how many instances there > > are, because in the final result they all have the same callback. > > > > thanks > > > > Anatoliy