R
Rainer Weikusat
To pull this again together for the benefit of people who might be
interested in the issue iself or who have or want to solve actual
problems with Perl:
It is easier to provide data inheritance with arrays than it is with
hashes because arrays 'decouple' the problem of providing a
user-friendly way of accessing object properties from the problem of
allocating 'locations to store properties' to individual packages/
classes: Only the number of slots a package needs matter for reserving
a suitable number of array locations and not their names. This means a
derived class can make a request like 'I need five properties' and
these can be placed in the array immediately after any superclass
allocations and so forth. The obvious problem that accessing
properties by index number isn't sensible can be resolved by declaring
constants which map 'friendly names' to slot numbers and with the help
of some fairly simple 'slot allocation code' like the one I posted in
the first posting of the 'needless flexibilities' thread, the
allocation itself can be automated altogether: All which remains to be
done for code which needs a number of reserved array slots accessible
by name is to declare the names and the name of the immediate
superclass in the data inheritance hierarchy (which might but doesn't
necessarily have to be identical to one of the packages listed in
@ISA --- this may be considered a needless complication [especially by
'deer oil' salesmen] but adding 'metaproperties' to @ISA beyond its
language-defined meaning doesn't seem sensible to me).
Such a scheme is inherently limited to single-inheritance situations
because there is no (easy) way to allocate different slot numbers to a
package appearing at different relative location in more than one
'data inheritance graph' (Is this the right term? I think a 'tree' is
something can only have a single root but this may be
wrong). Considering that languages which don't provide multiple
inheritance are widely used (IOW, Java), this restriction doesn't seem
to cripple an 'OO system' beyond the point of usefulness (which
coincides with my experience from 20+ years of 'OO
programming'). Since the problem of possible name collisions would
need to be resolved for hashes 'somehow', they don't offer an
out-of-the-box solution either and using hashes when their more
flexible slot allocation scheme is actually needed remains an option.
In addition to this, array accesses will usually be faster than hash
accesses because the mapping of names to slot numbers always happens
at compile time, a slot can be located by doing a simple calculation
(start of the array + slot number * size of a pointer) and there's no
risk that different names actually map to the same slot number (aka
'hash collisions') and that the accessing code has to perform a linear
search for a certain string key on a linked list (hash tables can be
implemented in other ways but this is the easiest, most common and
IMHO most sensible way). Because a hash table needs to be larger than
the number of keys actually stored in it, arrays will also tend to be
more compact than hashes (they will usually be larger than necessary
when growing dynamically in order to reduce the number of
reallocations which are need to cope with adding a sequence of new
elements to the end of an array).
Because of all this, I consider arrays a better choice as 'general
purpose' object representation object than hashes.
A remark about accessor methods
-------------------------------
Class users are not supposed to be aware of class implementation and
because of this, most 'object properties' shouldn't need "getter" and
"setter" methods (people who mutiliate their mother language in this
way without even thinking about it are generally not people whose
opinion on 'how to use language sensibly' matters ...). They usually
shouldn't be needed for access to the properties itself, either,
because derived classes are also class users and they also shouldn't
have to worry about implementation details of their ancestor classes,
not even at the (pseudo) 'abstract' level of 'somehow provided
properties with specific names'.
Since people are so fond of 'authorities':
http://git.kernel.org/cgit/linux/ke.../?id=dbec07bac614a61e3392c1e7c08cc6a49ad43f7a
NB: 'Accessor funtion' here isn't supposed to mean
static inline unsigned
get_core_internal_state__do_not_mess_with_it(struct ... *)
static inline void
set_core_internal_state__do_not_mess_with_it(struct ... *, unsigned)
That's just the 'next best option' the "But I WANT !! [Waeeeh!] to
mess with it" people have found for convincing others that they should
really be allowed to.
interested in the issue iself or who have or want to solve actual
problems with Perl:
It is easier to provide data inheritance with arrays than it is with
hashes because arrays 'decouple' the problem of providing a
user-friendly way of accessing object properties from the problem of
allocating 'locations to store properties' to individual packages/
classes: Only the number of slots a package needs matter for reserving
a suitable number of array locations and not their names. This means a
derived class can make a request like 'I need five properties' and
these can be placed in the array immediately after any superclass
allocations and so forth. The obvious problem that accessing
properties by index number isn't sensible can be resolved by declaring
constants which map 'friendly names' to slot numbers and with the help
of some fairly simple 'slot allocation code' like the one I posted in
the first posting of the 'needless flexibilities' thread, the
allocation itself can be automated altogether: All which remains to be
done for code which needs a number of reserved array slots accessible
by name is to declare the names and the name of the immediate
superclass in the data inheritance hierarchy (which might but doesn't
necessarily have to be identical to one of the packages listed in
@ISA --- this may be considered a needless complication [especially by
'deer oil' salesmen] but adding 'metaproperties' to @ISA beyond its
language-defined meaning doesn't seem sensible to me).
Such a scheme is inherently limited to single-inheritance situations
because there is no (easy) way to allocate different slot numbers to a
package appearing at different relative location in more than one
'data inheritance graph' (Is this the right term? I think a 'tree' is
something can only have a single root but this may be
wrong). Considering that languages which don't provide multiple
inheritance are widely used (IOW, Java), this restriction doesn't seem
to cripple an 'OO system' beyond the point of usefulness (which
coincides with my experience from 20+ years of 'OO
programming'). Since the problem of possible name collisions would
need to be resolved for hashes 'somehow', they don't offer an
out-of-the-box solution either and using hashes when their more
flexible slot allocation scheme is actually needed remains an option.
In addition to this, array accesses will usually be faster than hash
accesses because the mapping of names to slot numbers always happens
at compile time, a slot can be located by doing a simple calculation
(start of the array + slot number * size of a pointer) and there's no
risk that different names actually map to the same slot number (aka
'hash collisions') and that the accessing code has to perform a linear
search for a certain string key on a linked list (hash tables can be
implemented in other ways but this is the easiest, most common and
IMHO most sensible way). Because a hash table needs to be larger than
the number of keys actually stored in it, arrays will also tend to be
more compact than hashes (they will usually be larger than necessary
when growing dynamically in order to reduce the number of
reallocations which are need to cope with adding a sequence of new
elements to the end of an array).
Because of all this, I consider arrays a better choice as 'general
purpose' object representation object than hashes.
A remark about accessor methods
-------------------------------
Class users are not supposed to be aware of class implementation and
because of this, most 'object properties' shouldn't need "getter" and
"setter" methods (people who mutiliate their mother language in this
way without even thinking about it are generally not people whose
opinion on 'how to use language sensibly' matters ...). They usually
shouldn't be needed for access to the properties itself, either,
because derived classes are also class users and they also shouldn't
have to worry about implementation details of their ancestor classes,
not even at the (pseudo) 'abstract' level of 'somehow provided
properties with specific names'.
Since people are so fond of 'authorities':
http://git.kernel.org/cgit/linux/ke.../?id=dbec07bac614a61e3392c1e7c08cc6a49ad43f7a
NB: 'Accessor funtion' here isn't supposed to mean
static inline unsigned
get_core_internal_state__do_not_mess_with_it(struct ... *)
static inline void
set_core_internal_state__do_not_mess_with_it(struct ... *, unsigned)
That's just the 'next best option' the "But I WANT !! [Waeeeh!] to
mess with it" people have found for convincing others that they should
really be allowed to.