Welcome! Log In Create A New Profile

Advanced

[PHP] Question about __destruct()

Posted by Dan Joseph 
Dan Joseph
[PHP] Question about __destruct()
October 21, 2008 10:05PM
Hi,

I want to make sure I completely understand __destruct() and when its hit...

Understand that it will run if all references to a particular object are
removed, but is that also true when a page ends its execution?

Example, I call a database class. It constructs, connects, then my page
pulls some stuff out of the database, and then the php script ends. Does
this also cause the deconstruct to execute?

--
-Dan Joseph

www.canishosting.com - Plans start @ $1.99/month.

"Build a man a fire, and he will be warm for the rest of the day.
Light a man on fire, and will be warm for the rest of his life."
Mike van Riel
[PHP] Re: Question about __destruct()
October 21, 2008 11:00PM
Dan Joseph wrote:
> Hi,
>
> I want to make sure I completely understand __destruct() and when its hit...
>
> Understand that it will run if all references to a particular object are
> removed, but is that also true when a page ends its execution?
>
> Example, I call a database class. It constructs, connects, then my page
> pulls some stuff out of the database, and then the php script ends. Does
> this also cause the deconstruct to execute?
>

When a script ends everything is released (with some small exceptions),
thus also all references to instances of classes.
Thus AFAIK a deconstructor will always be called at the end of script
execution.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Jochem Maas
Re: [PHP] Re: Question about __destruct()
October 21, 2008 11:10PM
Mike van Riel schreef:
> Dan Joseph wrote:
>> Hi,
>>
>> I want to make sure I completely understand __destruct() and when its
>> hit...
>>
>> Understand that it will run if all references to a particular object are
>> removed, but is that also true when a page ends its execution?
>>
>> Example, I call a database class. It constructs, connects, then my page
>> pulls some stuff out of the database, and then the php script ends. Does
>> this also cause the deconstruct to execute?
>>
>
> When a script ends everything is released (with some small exceptions),
> thus also all references to instances of classes.
> Thus AFAIK a deconstructor will always be called at the end of script
> execution.
>

but you have no control over what order dtors are called and you can't make
any assumptions about state of file handles to STDIN/STDOUT and things like
that ... personally I find dtors run at end of script to be nigh on
useless.

>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Stut
Re: [PHP] Re: Question about __destruct()
October 21, 2008 11:15PM
On 21 Oct 2008, at 22:08, Jochem Maas wrote:
> Mike van Riel schreef:
>> Dan Joseph wrote:
>>> Hi,
>>>
>>> I want to make sure I completely understand __destruct() and when
>>> its
>>> hit...
>>>
>>> Understand that it will run if all references to a particular
>>> object are
>>> removed, but is that also true when a page ends its execution?
>>>
>>> Example, I call a database class. It constructs, connects, then
>>> my page
>>> pulls some stuff out of the database, and then the php script
>>> ends. Does
>>> this also cause the deconstruct to execute?
>>>
>>
>> When a script ends everything is released (with some small
>> exceptions),
>> thus also all references to instances of classes.
>> Thus AFAIK a deconstructor will always be called at the end of script
>> execution.
>>
>
> but you have no control over what order dtors are called and you
> can't make
> any assumptions about state of file handles to STDIN/STDOUT and
> things like
> that ... personally I find dtors run at end of script to be nigh on
> useless.

I use destructors to update dirty objects in memcache. I also use them
in my template class to optionally automagically output the footer
without needing an explicit call on each page.

They're far from useless.

-Stut

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Jochem Maas
Re: [PHP] Re: Question about __destruct()
October 22, 2008 01:25AM
Stut schreef:
> On 21 Oct 2008, at 22:08, Jochem Maas wrote:
>> Mike van Riel schreef:
>>> Dan Joseph wrote:
>>>> Hi,
>>>>
>>>> I want to make sure I completely understand __destruct() and when its
>>>> hit...
>>>>
>>>> Understand that it will run if all references to a particular object
>>>> are
>>>> removed, but is that also true when a page ends its execution?
>>>>
>>>> Example, I call a database class. It constructs, connects, then my
>>>> page
>>>> pulls some stuff out of the database, and then the php script ends.
>>>> Does
>>>> this also cause the deconstruct to execute?
>>>>
>>>
>>> When a script ends everything is released (with some small exceptions),
>>> thus also all references to instances of classes.
>>> Thus AFAIK a deconstructor will always be called at the end of script
>>> execution.
>>>
>>
>> but you have no control over what order dtors are called and you can't
>> make
>> any assumptions about state of file handles to STDIN/STDOUT and things
>> like
>> that ... personally I find dtors run at end of script to be nigh on
>> useless.
>
> I use destructors to update dirty objects in memcache.

care to eloborate ... sounds interesting.

I also use them
> in my template class to optionally automagically output the footer
> without needing an explicit call on each page.

not sure if I find that of much use, I see the validity but 1 LOC to
eplicitly output a page footer seems to me to be less of a wtf than
an(other) bit of auto-magic to save what is probably a very short simple
method call.

> They're far from useless.

true. but they are limited, there is no garantee any other object
will still exist when a particular dtor is run [at shutdown] which means a heavy OO
codebase cannot have object automated object interaction at shutdown ... there
are other gotchas (e.g. closed file descriptors to STDIN/STDOUT)

interaction with memcache though is a really good example. and I'd like to
learn a little more :-D

> -Stut
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Stut
Re: [PHP] Re: Question about __destruct()
October 22, 2008 10:30AM
On 22 Oct 2008, at 00:22, Jochem Maas wrote:
> Stut schreef:
>> I use destructors to update dirty objects in memcache.
>
> care to eloborate ... sounds interesting.

Nothing complicated. The core objects in my application are all cached
in memcache. If anything changes in an object it changes an internal
flag to indicate that it's dirty. The destructor checks that flag and
if the object is dirty it updates the cached version (the DB version
having been updated as changes were made).

> I also use them
>> in my template class to optionally automagically output the footer
>> without needing an explicit call on each page.
>
> not sure if I find that of much use, I see the validity but 1 LOC to
> eplicitly output a page footer seems to me to be less of a wtf than
> an(other) bit of auto-magic to save what is probably a very short
> simple
> method call.

It's one of the things that help to keep my controllers clean. The
pattern goes something like this...

$page = Layout::Create('style');
$page->title = 'This is the page title';
$page->keywords = 'shiny,happy,page';
$page->description = 'It\'s a shiny happy page.';
$page->Start();
$data = array();

// Business logic here populating $data with vars for the page template

$page->Render('dir/to/template.tpl.php', $data);

I've found that pattern works very well for me and not having to worry
about calling a method to output the footer it just one feature of a
very useful templating system.

>> They're far from useless.
>
> true. but they are limited, there is no garantee any other object
> will still exist when a particular dtor is run [at shutdown] which
> means a heavy OO
> codebase cannot have object automated object interaction at
> shutdown ... there
> are other gotchas (e.g. closed file descriptors to STDIN/STDOUT)

Agreed, you do need to be careful depending on what you want to
achieve. You've gotta remember that PHP is not (yet) an OOP language
at heart.

> interaction with memcache though is a really good example. and I'd
> like to
> learn a little more :-D

And I hope you did ;)

-Stut

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Jochem Maas
Re: [PHP] Re: Question about __destruct()
October 22, 2008 10:40AM
Stut schreef:
> On 22 Oct 2008, at 00:22, Jochem Maas wrote:
>> Stut schreef:
>>> I use destructors to update dirty objects in memcache.
>>
>> care to eloborate ... sounds interesting.
>
> Nothing complicated. The core objects in my application are all cached
> in memcache. If anything changes in an object it changes an internal
> flag to indicate that it's dirty. The destructor checks that flag and if
> the object is dirty it updates the cached version (the DB version having
> been updated as changes were made).

aha, I see, I take it these data object first check memcache for their
data before possibly making an attempt to hit the DB for data.

in your experience would dumping a result set of 50-60 rows from mysql
into memcache as a single entry be 'correct' - from my reading/playing with
memcache I don't see an issue but I was wondering if you had an opinion on
max. size of data for a single entry?

>
>> I also use them
>>> in my template class to optionally automagically output the footer
>>> without needing an explicit call on each page.
>>
>> not sure if I find that of much use, I see the validity but 1 LOC to
>> eplicitly output a page footer seems to me to be less of a wtf than
>> an(other) bit of auto-magic to save what is probably a very short simple
>> method call.
>
> It's one of the things that help to keep my controllers clean. The
> pattern goes something like this...
>
> $page = Layout::Create('style');
> $page->title = 'This is the page title';
> $page->keywords = 'shiny,happy,page';
> $page->description = 'It\'s a shiny happy page.';
> $page->Start();
> $data = array();
>
> // Business logic here populating $data with vars for the page template
>
> $page->Render('dir/to/template.tpl.php', $data);
>
> I've found that pattern works very well for me and not having to worry
> about calling a method to output the footer it just one feature of a
> very useful templating system.

package it up and call it VUTS :-)

>
>>> They're far from useless.
>>
>> true. but they are limited, there is no garantee any other object
>> will still exist when a particular dtor is run [at shutdown] which
>> means a heavy OO
>> codebase cannot have object automated object interaction at shutdown
>> ... there
>> are other gotchas (e.g. closed file descriptors to STDIN/STDOUT)
>
> Agreed, you do need to be careful depending on what you want to achieve.
> You've gotta remember that PHP is not (yet) an OOP language at heart.
>
>> interaction with memcache though is a really good example. and I'd
>> like to
>> learn a little more :-D
>
> And I hope you did ;)

yes, thanks for the info!

>
> -Stut
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Dan Joseph
Re: [PHP] Re: Question about __destruct()
October 22, 2008 03:45PM
On Tue, Oct 21, 2008 at 5:14 PM, Stut <[email protected]> wrote:

>
>
>>> When a script ends everything is released (with some small exceptions),
>>> thus also all references to instances of classes.
>>> Thus AFAIK a deconstructor will always be called at the end of script
>>> execution.
>>>
>>>
>> but you have no control over what order dtors are called and you can't
>> make
>> any assumptions about state of file handles to STDIN/STDOUT and things
>> like
>> that ... personally I find dtors run at end of script to be nigh on
>> useless.
>>
>
> I use destructors to update dirty objects in memcache. I also use them in
> my template class to optionally automagically output the footer without
> needing an explicit call on each page.
>


Never any issues this way? They always run without a hitch?

--
-Dan Joseph

www.canishosting.com - Plans start @ $1.99/month.

"Build a man a fire, and he will be warm for the rest of the day.
Light a man on fire, and will be warm for the rest of his life."
Eric Butera
Re: [PHP] Re: Question about __destruct()
October 22, 2008 05:00PM
On Wed, Oct 22, 2008 at 9:42 AM, Dan Joseph <[email protected]> wrote:
> On Tue, Oct 21, 2008 at 5:14 PM, Stut <[email protected]> wrote:
>
>>
>>
>>>> When a script ends everything is released (with some small exceptions),
>>>> thus also all references to instances of classes.
>>>> Thus AFAIK a deconstructor will always be called at the end of script
>>>> execution.
>>>>
>>>>
>>> but you have no control over what order dtors are called and you can't
>>> make
>>> any assumptions about state of file handles to STDIN/STDOUT and things
>>> like
>>> that ... personally I find dtors run at end of script to be nigh on
>>> useless.
>>>
>>
>> I use destructors to update dirty objects in memcache. I also use them in
>> my template class to optionally automagically output the footer without
>> needing an explicit call on each page.
>>
>
>
> Never any issues this way? They always run without a hitch?
>
> --
> -Dan Joseph
>
> www.canishosting.com - Plans start @ $1.99/month.
>
> "Build a man a fire, and he will be warm for the rest of the day.
> Light a man on fire, and will be warm for the rest of his life."
>

Don't throw exceptions in your dtors. Hilarity will not ensue. There
are some good use cases for them as others have stated, but I'd
recommend staying away unless you really need it. I've only ever used
dtors for closing query results and gd resources. Trivial stuff to
just try and lower the memory usage but isn't really necessary. In
general though I stay away from them as most of my code is front-end
meaning everything is tore down at the end of the request anyways.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Stut
Re: [PHP] Re: Question about __destruct()
October 22, 2008 08:35PM
On 22 Oct 2008, at 14:42, Dan Joseph wrote:
> On Tue, Oct 21, 2008 at 5:14 PM, Stut <[email protected]> wrote:
>>>> When a script ends everything is released (with some small
>>>> exceptions),
>>>> thus also all references to instances of classes.
>>>> Thus AFAIK a deconstructor will always be called at the end of
>>>> script
>>>> execution.
>>>>
>>> but you have no control over what order dtors are called and you
>>> can't
>>> make
>>> any assumptions about state of file handles to STDIN/STDOUT and
>>> things
>>> like
>>> that ... personally I find dtors run at end of script to be nigh on
>>> useless.
>>>
>> I use destructors to update dirty objects in memcache. I also use
>> them in
>> my template class to optionally automagically output the footer
>> without
>> needing an explicit call on each page.
>
> Never any issues this way? They always run without a hitch?

Not had any issues to far, and it's being used on some pretty busy
sites and various PHP versions and several different web servers.

-Stut

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Stut
Re: [PHP] Re: Question about __destruct()
October 22, 2008 08:40PM
On 22 Oct 2008, at 09:35, Jochem Maas wrote:
> Stut schreef:
>> On 22 Oct 2008, at 00:22, Jochem Maas wrote:
>>> Stut schreef:
>>>> I use destructors to update dirty objects in memcache.
>>>
>>> care to eloborate ... sounds interesting.
>>
>> Nothing complicated. The core objects in my application are all
>> cached
>> in memcache. If anything changes in an object it changes an internal
>> flag to indicate that it's dirty. The destructor checks that flag
>> and if
>> the object is dirty it updates the cached version (the DB version
>> having
>> been updated as changes were made).
>
> aha, I see, I take it these data object first check memcache for their
> data before possibly making an attempt to hit the DB for data.
>
> in your experience would dumping a result set of 50-60 rows from mysql
> into memcache as a single entry be 'correct' - from my reading/
> playing with
> memcache I don't see an issue but I was wondering if you had an
> opinion on
> max. size of data for a single entry?

There is a size limit known as the slab size. I believe by default
this is set to 1MB. The only thing to bear in mind is the network
traffic you'll be creating when you store large objects. You need to
weigh up the size against how often you'll be retrieving it.

Personally, if I were anywhere over a few kB in a single entry I'd
look at whether I really need everything in that entry each time or if
it's possible to break it up into smaller pieces.

>>>> I also use them
>>>> in my template class to optionally automagically output the footer
>>>> without needing an explicit call on each page.
>>>
>>> not sure if I find that of much use, I see the validity but 1 LOC to
>>> eplicitly output a page footer seems to me to be less of a wtf than
>>> an(other) bit of auto-magic to save what is probably a very short
>>> simple
>>> method call.
>>
>> It's one of the things that help to keep my controllers clean. The
>> pattern goes something like this...
>>
>> $page = Layout::Create('style');
>> $page->title = 'This is the page title';
>> $page->keywords = 'shiny,happy,page';
>> $page->description = 'It\'s a shiny happy page.';
>> $page->Start();
>> $data = array();
>>
>> // Business logic here populating $data with vars for the page
>> template
>>
>> $page->Render('dir/to/template.tpl.php', $data);
>>
>> I've found that pattern works very well for me and not having to
>> worry
>> about calling a method to output the footer it just one feature of a
>> very useful templating system.
>
> package it up and call it VUTS :-)

SVUTS!!!

>>>> They're far from useless.
>>>
>>> true. but they are limited, there is no garantee any other object
>>> will still exist when a particular dtor is run [at shutdown] which
>>> means a heavy OO
>>> codebase cannot have object automated object interaction at shutdown
>>> ... there
>>> are other gotchas (e.g. closed file descriptors to STDIN/STDOUT)
>>
>> Agreed, you do need to be careful depending on what you want to
>> achieve.
>> You've gotta remember that PHP is not (yet) an OOP language at heart.
>>
>>> interaction with memcache though is a really good example. and I'd
>>> like to
>>> learn a little more :-D
>>
>> And I hope you did ;)
>
> yes, thanks for the info!

Sharing is good mmm'kay!

-Stut

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Dan Joseph
Re: [PHP] Re: Question about __destruct()
October 22, 2008 09:15PM
On Wed, Oct 22, 2008 at 2:29 PM, Stut <[email protected]> wrote:

>
> Never any issues this way? They always run without a hitch?
>>
>
> Not had any issues to far, and it's being used on some pretty busy sites
> and various PHP versions and several different web servers.
>
>
Terrific! Thanks for the information!

--
-Dan Joseph

www.canishosting.com - Plans start @ $1.99/month.

"Build a man a fire, and he will be warm for the rest of the day.
Light a man on fire, and will be warm for the rest of his life."
Sorry, only registered users may post in this forum.

Click here to login