object representation redux (term?)

Discussion in 'Perl Misc' started by Rainer Weikusat, Mar 22, 2013.

  1. 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.
    Rainer Weikusat, Mar 22, 2013
    #1
    1. Advertising

  2. Rainer Weikusat

    Ted Zlatanov Guest

    On Fri, 22 Mar 2013 10:51:15 +0000 Rainer Weikusat <> wrote:

    RW> To pull this again together for the benefit of people who might be
    RW> interested in the issue iself or who have or want to solve actual
    RW> problems with Perl:

    [rest omitted]

    Please, stop. You've written enough (on this).

    Ted
    Ted Zlatanov, Mar 22, 2013
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neo Geshel
    Replies:
    5
    Views:
    427
    Neo Geshel
    Mar 13, 2006
  2. kc
    Replies:
    3
    Views:
    8,342
  3. Replies:
    34
    Views:
    1,259
    Neredbojias
    Jun 3, 2006
  4. legere

    SICP in Python, redux

    legere, Jun 29, 2003, in forum: Python
    Replies:
    0
    Views:
    1,773
    legere
    Jun 29, 2003
  5. Guido van Rossum
    Replies:
    21
    Views:
    596
    Steven Bethard
    Jun 6, 2005
Loading...

Share This Page