A remark about 'field hashes'

[Rainer Weikusat]

I've had a closer look at this out of curiosity (beyond my initial
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
properties

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

[Rainer Weikusat]

Rainer Weikusat <rwei...@mssgmbh.com> writes:

[...]

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

This should have been 'times the average number of fields per object'.

[Ben Morrow]

Quoth Rainer Weikusat <rwei...@mssgmbh.com>:

> I've had a closer look at this out of curiosity (beyond my initial
> 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')

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.

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

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{$self} rather than
$hash{refaddr $self}.

> - the amount of work which needs to be performed when an
> object is destroyed is proportional to the number of
> properties

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

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

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.

> - with a naive implementation, the same (uselessly) happens
> 'during global destruction'

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.

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

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.

Ben

[George Mpouras]

by defintion there is no such thing as self contained ensemble