|Do you know where your variables are?|
Flyweight Objects and garbage collectionby BlaisePascal (Monk)
|on Sep 04, 2000 at 20:17 UTC||Need Help??|
BlaisePascal has asked for the wisdom of the Perl Monks concerning the following question:
I was reading the excerpts of Damian Conway's OO Perl book that are on his website (while waiting for my paycheck to clear so I can order the book itself). Among lots of other useful things, he describes a technique for data encapsulation using flyweight objects:
His example was more useful than the "foo" class above, but this shows the basic idea. The actual objects are held in a dataspace lexically scoped to the package, and is inaccessible outside the package. Outside the package, all the rest of the world gets is a blessed handle to the data locked away in the package, and can't see anything to directly manipulate.
There does seem to be some limitations to this approach (such as difficulty doing inheritance, etc), but the one major question I have is with GC.
The actual objects are referred to by the array @foos, and only the array @foos. When the blessed handle goes out of scope, the object won't be cleaned up, because it is still being referred to by @foos. Only when the program exits will the object itself be cleaned. This could be a problem.
The obvious solution would be to add something like:
to the Foo class. Then, when the handle goes out of scope, Foo::DESTROY gets called, and all is well.
What I'm concerned about is cases where the handle gets copied before it goes out of scope:
At the end of usesfoo, $foo falls out of scope. Is Perl smart enough to not call DESTROY $foo at that point, or will the copy of $foo saved in the return value be rendered useless?
Damian Conway's example does not include a destructor, so I can't tell by his example -- his looks to me like it leaks memory.