Hello Andi,
Tuesday, February 10, 2004, 11:29:16 AM, you wrote:
> At 10:49 AM 2/10/2004 +0100, Eric Daspet wrote:
>>Andi Gutmans wrote:
>>>At 03:55 PM 2/9/2004 +, Stephane Drouard wrote:
IMO, this is bad programming. If an object wants to access another
object (global or not), it has
At 10:49 AM 2/10/2004 +0100, Eric Daspet wrote:
Andi Gutmans wrote:
At 03:55 PM 2/9/2004 +, Stephane Drouard wrote:
IMO, this is bad programming. If an object wants to access another
object (global or not), it has to own a reference on it
You are getting into coding style now.
It is coding st
Andi Gutmans wrote:
At 03:55 PM 2/9/2004 +, Stephane Drouard wrote:
IMO, this is bad programming. If an object wants to access another object
(global or not), it has to own a reference on it
You are getting into coding style now.
It is coding style, you are right.
However, order of destructor
I guess the way the implementation works is quite fine. But i guess leaving
the calls in a random order gives the use of the destructors a quite bad
taste. The current implementation leaves many room for 'try and error'
writing of code as you are almost unable to make things work the way
you would
At 03:55 PM 2/9/2004 +, Stephane Drouard wrote:
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> He doesn't necessarily own a reference but tries to access it in the
> destructor.
IMO, this is bad programming. If an object wants to access another object
(global or not), it has to own
== Quote from Eric Daspet ([EMAIL PROTECTED])'s article
> Be carreful, this does not resolve all things :
>
> $source1 = new stdClass ;
> $source2 = new stdClass ;
> $source3 = new stdClass ;
> $refLevel1 = new stdClass ;
> $refLevel2 = new stdClass ;
>
> $source1->ref = $refLevel1 ;
> $source2->re
Stephane Drouard wrote:
Couldn't PHP destroy global objects by taking their refcount into
account? All objects with refcount=1 are first destroyed, then all
objects with refcount=2, and so on... Objects with a same refcount
are destroyed in a random "order".
Be carreful, this does not resolve all
== Quote from Stephane Drouard ([EMAIL PROTECTED])'s article
> == Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> > He doesn't necessarily own a reference but tries to access it in the
> > destructor.
>
> IMO, this is bad programming. If an object wants to access another object (global or
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> He doesn't necessarily own a reference but tries to access it in the
> destructor.
IMO, this is bad programming. If an object wants to access another object (global or
not), it has to own a reference on it, to guaranty the referenced obje
At 01:36 PM 2/9/2004 +, Stephane Drouard wrote:
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> They're not locked to 1, and nothing in a symbol table will ever be with a
> refcount of less than 1... But generally, all global variables (or for
> that matter, all variables period) ha
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> They're not locked to 1, and nothing in a symbol table will ever be with a
> refcount of less than 1... But generally, all global variables (or for
> that matter, all variables period) have a refcount of 1, unless you do
> something 'speci
At 12:38 09/02/2004, Stephane Drouard wrote:
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> If you're talking about destruction that honors reference counts (which has
> nothing to do with order, it's still randomly-ordered), then yes, it's
> *generally* ok.
Yes, I was talking about tha
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> If you're talking about destruction that honors reference counts (which has
> nothing to do with order, it's still randomly-ordered), then yes, it's
> *generally* ok.
Yes, I was talking about that point.
> But that what we had before, an
At 12:03 07/02/2004, Stephane Drouard wrote:
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> To make a long story short, no. Circular references are hardly the
> problem, even a one-sided reference can be problematic. Just one example
> (there are many others) - you have $container and
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> To make a long story short, no. Circular references are hardly the
> problem, even a one-sided reference can be problematic. Just one example
> (there are many others) - you have $container and $obj, both are global
> variables, $containe
At 22:19 06/02/2004, Michael Walter wrote:
Usually, it is sufficient to deconstruct in reverse construction order in
this case:
$obj=PLA;
$container=...;
Hence, destruction order is $container, $obj -- no problem (unless you're
dealing with circular references, which actually are the problem I t
Zeev Suraski wrote:
At 13:01 06/02/2004, Stephane Drouard wrote:
== Quote from Red Wingate ([EMAIL PROTECTED])'s article
> Is the removal of a specific order on the __destruct() calls
> necessary? It's a pain in the ass the be unable to predict
> in which order the __destruct() calls are made.
I d
At 13:01 06/02/2004, Stephane Drouard wrote:
== Quote from Red Wingate ([EMAIL PROTECTED])'s article
> Is the removal of a specific order on the __destruct() calls
> necessary? It's a pain in the ass the be unable to predict
> in which order the __destruct() calls are made.
I did the following test
On Fri, 2004-02-06 at 06:01, Stephane Drouard wrote:
> Couldn't PHP implement global object destruction that way:
> * firstly try to destroyed them in the same way as for local
> variables (respecting dependences),
> * for objects that were not destroyed in the first step (certainly
> circular re
On Fri, 06 Feb 2004, Zeev Suraski wrote:
> Yeah, assuming they're PHP-style objects (zend_object structure) then yes,
> it should work fine.
Well, they look something like:
typedef struct {
zend_object zobj;
void *p;
dtor_t dtor;
} my_object;
- Andrei
--
PHP Internals - PHP Runtime Deve
Stephane Drouard wrote:
== Quote from Red Wingate ([EMAIL PROTECTED])'s article
Is the removal of a specific order on the __destruct() calls
necessary? It's a pain in the ass the be unable to predict
in which order the __destruct() calls are made.
[..]
Couldn't PHP implement global object destruct
== Quote from Red Wingate ([EMAIL PROTECTED])'s article
> Is the removal of a specific order on the __destruct() calls
> necessary? It's a pain in the ass the be unable to predict
> in which order the __destruct() calls are made.
I did the following test:
n = $n;
}
function __destruct() {
Is the removal of a specific order on the __destruct() calls
necessary? It's a pain in the ass the be unable to predict
in which order the __destruct() calls are made.
error_log;
}
function __destruct () {
// Dump Error-Log to User ( E-Mail, HTML etc. )
}
}
At 23:16 05/02/2004, Andrei Zmievski wrote:
On Thu, 05 Feb 2004, Zeev Suraski wrote:
> Internal objects as in the ones in reflection and similar? Yes. But I'd
> imagine that for most other objects which completely overload the
behavior,
> you wouldn't need that. Generally, if your object should
On Thu, 05 Feb 2004, Zeev Suraski wrote:
> Internal objects as in the ones in reflection and similar? Yes. But I'd
> imagine that for most other objects which completely overload the behavior,
> you wouldn't need that. Generally, if your object should be able to call
> __destruct() *AND* it's
At 02:00 05/02/2004, Marcus Boerger wrote:
Hello Zeev,
Thursday, February 5, 2004, 12:24:47 AM, you wrote:
> At 23:45 04/02/2004, Andrei Zmievski wrote:
>>On Wed, 04 Feb 2004, Andi Gutmans wrote:
>> > 3. The APIs have changed to allow for this new mechanism. Instead
of the
>> > previous dtor c
At 01:00 AM 2/5/2004 +0100, Marcus Boerger wrote:
> If it's a PHP-style object, then you can use zend_objects_destroy_object as
> your destructor callback (when calling zend_objects_store_put()), in which
> case __destruct() will be called. That's how the regular PHP objects
do it.
So my guess i
Hello Zeev,
Thursday, February 5, 2004, 12:24:47 AM, you wrote:
> At 23:45 04/02/2004, Andrei Zmievski wrote:
>>On Wed, 04 Feb 2004, Andi Gutmans wrote:
>> > 3. The APIs have changed to allow for this new mechanism. Instead of the
>> > previous dtor callback, which was supposed to both call the
At 23:45 04/02/2004, Andrei Zmievski wrote:
On Wed, 04 Feb 2004, Andi Gutmans wrote:
> 3. The APIs have changed to allow for this new mechanism. Instead of the
> previous dtor callback, which was supposed to both call the destructor and
> free the object's storage, there are now two separate call
Hi Andi,
Andi Gutmans wrote:
> [...]
>
> This has several implications:
>
> [...]
>
> 2. A *VERY* important implication is that you cannot, and must not
rely in any way on the order of destruction during shutdown. It runs in
no particular order. That means that by the time the destructor for
On Wed, 04 Feb 2004, Andi Gutmans wrote:
> 3. The APIs have changed to allow for this new mechanism. Instead of the
> previous dtor callback, which was supposed to both call the destructor and
> free the object's storage, there are now two separate callbacks - dtor
> (call the destructor) and
31 matches
Mail list logo
