Re: Re: Question about __destruct()

From: Date: Wed, 22 Oct 2008 18:34:12 +0000
Subject: Re: Re: Question about __destruct()
References: 1 2 3 4 5 6 7  Groups: php.general 
Request: Send a blank email to php-general+get-282280@lists.php.net to get a copy of this message
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/

« previous php.general (#282280) next »