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