Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- A remark about 'field hashes'
- Rainer Weikusat
June 18, 2013, 4:59 pm
rate this thread
assessment as 'useless module'): This is actually based on the idea to
define a hash per 'object property' and use the 'object id' as index
into the hash in order to obtain the value. Besides forcing users to
use hashes for storing object properties (something some people
presumably consider to be 'a feature') this means
- every access to a property needs to turn the object into an
object id and go through a 'gatekeeper abstraction' (which
people who misunderstood the Java Beans specification as
being concerned with objects accessing their own properties
instead of objects accessing properties of other object
presumably also consider a feature since it eliminates the
advantages of the other approach)
- the amount of work which needs to be performed when an
object is destroyed is proportional to the number of
- the amount of work which needs to be performed when creating
a new ithread (IMHO not a good idea) is proportional to the
number of objects times the number of fields
- with a naive implementation, the same (uselessly) happens
'during global destruction'
IMO, a better idea is to use a package global hash to associate an
object (via refaddr) with a hash or array reference and use that in
the conventional way. This way, destroying a single object needs only
a single deletion, the amount of work necessary to clone or terminate
an interpreter is proportional to the number of objects and a method
can use a single lookup/ function call to gain access to the 'state
object' of the current instance and use that directly afterwards.
Re: A remark about 'field hashes'
I don't know what you mean here. The point of HUF is to make it easier
to store object properties in refaddr-keyed hashes, if that is what you
want to do. If you don't want to do that, you don't need to use it.
Again, this is just a consequence of the initial assumption, that you
want to store properties in refaddr-keyed hashes. HUF actually removes a
step, in that you can access the hash with $hash rather than
That is also true with a plain hash and an explicit destructor, except
that that work is being done in Perl rather than C, and is so
Of course. It was anyway: creating an ithread clones the entire
interpreter, including all data structures. The point of HUF is that,
since it is a core feature, it can hook into that cloning process and
rekey the hashes to the object's new refaddr at the same time. Without
HUF you would have to write a CLONE method in Perl to do this for you.
I'm not sure what you mean here. During global destruction, all perl
values must be destroyed; those with DESTROY methods must be destroyed
individually, and the rest can be destroyed simply by deallocating them.
An object storing values in plain hashes with a DESTROY method to clean
out those hashes will have to be destroyed properly, with the method,
since perl has no way of knowing the method is only going to destroy
things that were being destroyed anyway. Since a fieldhash uses backref
magic rather than a DESTROY method, it doesn't need to do this, and the
values in the hashes will be freed in the normal way (that is, they will
only be explicitly freed if they have DESTROY methods or destruction
magic of their own).
This is actually another advantage of fieldhashes: it's possible to
safely store properties against arbitrary objects, *without* having to
modify the objects to include a DESTROY method to clear out the hashes.
That's perfectly sensible; however, that package global hash should be a
fieldhash. Otherwise you're back to writing your own DESTROY and CLONE
methods to keep it in sync with the existing objects. I realise the HUF
documentation assumes you will use one hash per property, but there's no
reason you have to stick to that convention if you don't want to.
- » Having trouble parsing JSON structure with JSON package
- — Previous thread in » PERL Discussions
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — The site's Newest Thread. Posted in » Secure Shell Forum