Another suggestion, as given by chip in this node was to use unique IDs that are stored in a package level hash, such that the Factory class stores only these IDs, which does not appear to increase the reference count to the object, such that they can be deleted when they go out of scope. The only problem with this, potentially, is that the counter that acts like a unique ID could roll over, but realistically I would not expect that to happen.
However, thinking about this and any other way to generate a sufficientl unique ID, I though about stringifying the references as a unique ID, that is, instead of this code that chip offered:
I would use:$TEMPS{ $self->{ID} = ++$TEMPID } = $self;
Is there any serious problems with this? As opposed to the int case, these will stop to resolve right once your memory is full, which problems would be expected to happen anyway. I'm pretty sure that references would remain fixed in memory once created, but I can't see any other caveats. Any concerns about this?$TEMPS{ $self->{ID} = "$self" } = $self;
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important
In reply to Using stringified refs for unique IDs? by Masem
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |