in reply to Garbage collected class attributes with inside out classes.

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.

  • Comment on Re: Garbage collected class attributes with inside out classes.

Replies are listed 'Best First'.
Re^2: Garbage collected class attributes with inside out classes.
by kyle (Abbot) on Mar 02, 2007 at 03:16 UTC

    ...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 );
}

      [download]

      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]

In Section Meditations