Re: Garbage collected class attributes with inside out classes.
by Anno (Deacon) on Mar 01, 2007 at 17:44 UTC
|
Interesting concept. I have never wanted to garbage-collect class variables, but I see how the need can arise.
So in your first implementation the class variables are essentially just extra attributes. Smoke, mirrors, and an additional level of indirection take care that all objects see the same shared data structure.
About the second implementation (which I spontaneously like more for its simplicity) you say
What's bad: There's an extra variable that you can't get rid of but also isn't part of the core functionality.
Well, you just might get rid of the extra variable. Looking at the hash that implements a standard attribute, the normal course of things is that every object creates a new key on initializatiation which stays around until the object is collected. Thus scalar keys %hash is the count of objects that have been initialized in the class. Any such hash could replace the dedicated counter variable. Unless the class does things like delete entries from the hash at will, but that's unusual, and probably cruel.
Anno | [reply] [d/l] |
|
Well, you just might get rid of the extra variable.
Yes. I actually mentioned this in an earlier draft, but I took it out. If you have some regular attribute stored in a hash, and you're guaranteed that it always has a value (and typically that's true), you can use that to tell when you're the last object to be destroyed.
What I don't like about that method is that it ties proper destruction to something that's not otherwise related to it. Say there are many attributes, and you pick one to be your surrogate counter. A programmer who comes to look later might wonder why that one? If the attribute you choose changes (its name, or the fact that it always gets a value), the destructor has to change too. You can (and should) make all that explicit in comments to avoid confusion, but having a separate counter is self documenting.
| [reply] |
|
Those are valid concerns, at least in the context of a one-off implementation. If you think of it as (say) an additional feature of Class::Std, the choice of the "representative attribute" would be abstract (probably the first, or last, attribute declared in the class) and rather obvious. The ugliness would be hidden in the general destructor.
Come to think of it, there's a problem with classes that don't have (their own) object attributes, but still want destructible class data. Normal garbage collection would likely ignore such a class, so it can't be used as a trigger.
You'd need a dummy attribute or some such.
Your more intricate first implementation would still work, if only because the class attributes are implemented as object attributes, so the case doesn't arise.
Unrelatedly, I think your writeup would be easier to read if you swapped the two implementations, so the simple one comes first and can serve as an introduction.
Anno
| [reply] [d/l] |
Re: Garbage collected class attributes with inside out classes.
by eric256 (Parson) on Mar 01, 2007 at 22:35 UTC
|
I'm a bit confused the docs for Class::Std say "Every class that loads the Class::Std module automatically has a DESTROY() destructor, which automatically cleans up any attributes declared with the :ATTR() trait (see below)." So doesn't that mean it already handles this? If it doesn't wouldn't it work to catch the DESTROY of each object and removes its attributes as the objects died? There is the definite possibility that I'm talking about something completely different than you! ;)
| [reply] [d/l] |
|
The documentation is correct, of course!
In my first implementation, the class attributes are declared as :ATTR, and they behave as described. That's why that implementation does not have its own DEMOLISH (called by the Class::Std DESTROY). That is, in a way, its advantage. You do your work up front in a way that the module takes care of the rest of the work at the end.
The difference between what I have declared as :ATTR and what is normally declared as :ATTR is that normally the elements of the hash are all different. Each instance has its own key and value. In my case, the values of an individual hash are all the same—one reference shared by every instance. (Each still has its own key, but they all have the same value.) I'm tricking the instance attributes into behaving as class attributes.
In the second implementation, the class attributes are not declared as :ATTR at all, so I have to clean them up myself with my own DEMOLISH.
| [reply] [d/l] [select] |
|
I think I understand now. So you are talking about having class attributes along side the instance attributes? If that is the case wouldn't you want the class attributes to exist until the program terminated in case you created a new instance after all the others where destroyed?
This my ($other_ident) = keys %example_hash_of; is confusing me, what does that do? It would seem that its just grabbing the first key in the hash regardless of what it is.
I have the distinct feeling I'm confusing the trees with the forest here, but I'm also determined to understand!
| [reply] [d/l] |
|
Re: Garbage collected class attributes with inside out classes.
by xdg (Monsignor) on Mar 02, 2007 at 01:55 UTC
|
There's an extra variable that you can't get rid of but also isn't part of the core functionality
So? It's a single scalar. And arguably, it is part of the core functionality -- if you define garbage collection of class variables to recover memory as core.
The other options I thought about involved weak references but that's really just another mechanism for doing what you're doing in #1.
Overall -- an interesting meditation. To some extent, I question whether this is really a "class attribute" in the usual sense of the term, as it only exists when objects exist, but that's just quibbling over names.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
|
...if you define garbage collection of class variables to recover memory as core.
Well, I guess I don't. Garbage collection of variables is kind of like taking out the trash in the kitchen. It's not exactly my purpose in life. These objects don't have any purpose in life beyond being an example, but real ones have better things to do than collect garbage. On the other hand, lots of other objects have to have destructors to clean up after themselves, and you don't see me bellyaching about that.
The other options I thought about involved weak references...
I'd be interested to see that!
To some extent, I question whether this is really a "class attribute" in the usual sense of the term, as it only exists when objects exist, but that's just quibbling over names.
I agree, but I'm not sure what else I'd call it.
| [reply] |
|
Well, I guess I don't.
If minimal memory consumption is part of the "spec" that you are attempting to deliver (i.e. a non-functional requirement), then I'd call it core and wouldn't worry about an extra scalar and code to implement the larger savings. If it isn't part of your spec, then this may be a case of premature optimization.
On the weak reference idea, it was really just equivalent to your #1 -- but using an extra (weak) reference instead of just copying the reference from the first value in the hash. No better and perhaps even worse.
# simplified example
use Scalar::Util qw/weaken/;
my $weak_class_ref;
sub BUILD {
my ($self, $ident, $args_ref) = @_;
$weak_class_ref ||= {};
$example_hash_of{$ident} = $weak_class_ref;
weaken( $weak_class_ref );
}
The other idea I had was to have a separate singleton class that you assign into every object during initialization. But that still just moves the problem of cleaning up when no "live" objects exist into the singleton class.
You want common data to spring into existence when you have objects and spring back out of existence when there are no objects. I don't see any alternative to keeping a count of objects or copying the reference over during construction (and thus letting Perl keep the reference count for you).
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] [d/l] |
Re: Garbage collected class attributes with inside out classes.
by rir (Vicar) on Mar 02, 2007 at 02:09 UTC
|
I would reference count and put a closure around my $counter.
Be well
rir | [reply] |
|
| [reply] |
|
Just that I'd limit the counter variable to the routines that need it; so it seems that the variable doesn't exist
in parts of your class that are outside the scope created
by the outermost brackets below.
{
my $count; # Number of class instances that exist.
sub BUILD {
++$count;
#
}
sub DEMOLISH {
--$count;
#
}
}
Be well, rir | [reply] [d/l] |
Re: Garbage collected class attributes with inside out classes.
by Moron (Curate) on Mar 02, 2007 at 15:11 UTC
|
There's this (not-too-daft) idea going around that the user of a module shouldn't have to "consciously" garbage-collect instances - they should just collapse when the instance reference goes out of scope. But in this example that clearly won't work, so if there's no other way, a DESTROY method is going to be necessary.But I would try to make the class autodestructible from the outset if at all possible - having to DESTROY is certainly going to confuse some people.
| [reply] |