Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: Garbage collected class attributes with inside out classes.

by Anno (Deacon)
on Mar 01, 2007 at 17:44 UTC ( [id://602730]=note: print w/replies, xml ) Need Help??


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

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

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

    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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://602730]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2024-03-29 07:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found