http://qs1969.pair.com?node_id=602707

Having class attributes with an inside out class is pretty straight forward. Just use a regular lexical variable next to the hashes you use to hold your instance attributes. Without some extra logic, however, those variables will hold their values even after the last instance of your class has disappeared.

Say one of those class variables holds a large data structure that you don't want hanging around in memory when it's not needed. You want to have a class attribute that gets garbage collected when the last instance is destroyed.

In my first implementation, each class attribute is held as a reference, and each instance has a copy of that one reference. When the last instance is destroyed, the last reference disappears, and that mammoth data structure gets destroyed too.

use Class::Std; my %example_array_of :ATTR; my %example_hash_of :ATTR; my %example_scalar_of :ATTR; sub BUILD { my ($self, $ident, $args_ref) = @_; my ($other_ident) = keys %example_hash_of; if ( $other_ident ) { $example_array_of{$ident} = $example_array_of{$other_ident}; $example_hash_of{$ident} = $example_hash_of{$other_ident}; $example_scalar_of{$ident} = $example_scalar_of{$other_ident}; } else { $example_array_of{$ident} = []; $example_hash_of{$ident} = {}; $example_scalar_of{$ident} = \do{ my $x = undef }; } } sub get_example_array { return @{$example_array_of{ident shift}}; } sub set_example_array { my $self = shift; @{$example_array_of{ident $self}} = @_; }

What's good: All the work is done at construction, when you are probably doing some initialization work anyway.

What's bad: The initialization is a clutter. The accessors are expensive because of the dereferencing.

An alternate method is to count references in a separate class attribute—a method that is not really specific to inside out objects at all. When the destructor detects that it is destroying the last instance, it undefs each of the class attributes.

use Class::Std; my @example_array; my %example_hash; my $example_scalar; my $instance_count = 0; sub BUILD { my ($self, $ident, $args_ref) = @_; $instance_count++; } sub DEMOLISH { my ( $self, $ident ) = @_; if ( ! --$instance_count ) { undef %example_hash; undef @example_array; undef $example_scalar; } } sub get_example_array { return @example_array; } sub set_example_array { shift; @example_array = @_; }

What's good: It's fast, clean, and simple to understand.

What's bad: There's an extra variable that you can't get rid of but also isn't part of the core functionality.

I've offered two possibilities here. What do the other monks do in this situation?

Replies are listed 'Best First'.
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

      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.

        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

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! ;)


    ___________
    Eric Hodges

      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.

        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!


        ___________
        Eric Hodges
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.

      ...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.

        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.

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

      This sounds simple, but I still don't know what you mean. Could you show code for this?

        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
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.

    -M

    Free your mind