Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
>NI> You just re-invented "look up the name in a hash table" ;-)
>
>I thought I was saving the constant search along the @ISA, do it only
>once.

perl5 does that.

>
>And adding a direct pointer for constant methods. ($foo->aMethod).

Perl5.6.0 saves pre-hashed name of constant methods. It still does
the hash lookup though - as it does not know which class'es stash 
will be used till it sees the object

You were proposing saving the index into the lookup table which would 
be an improvement. The snag being that a runtime "require X;"  can 
invalidate the name to index mapping so we still have to save name
and a "generation number" in the op to know when index is stale and 
needs to be re-looked up in the hash. 

You have also traded existing "stash is a hash" structure for 
a per-package (sparse?) array + auxillary name => index mapping.

We had two schemes for name->index mapping:

1. Big global hash with name -> index which increases as names are added
    + names => index mapping does not get stale
    - package methods arrays are sparse

2. Per-class hash of name -> index mappings
    + method arrays are dense
    - name -> index mapping changes as class hierachy changes
    - computing non-conflicting indices is a complex algorithm.

I think a version of (1) is most promising:
  * We are going to want to look at sparse arrays anyway.
  * We may be able to make array sparse in an interesting way
    which leads to "clumps" which would fit well with (say) B-tree
    as the "array".
  * Even if we use index as "key" into a hash-as-sparse-array
    the operations on an integer key are much simpler:

    With a chained hash ...

    entry = table[index % num_entries];
    while (entry && entry->index != index)
     {
      entry = entry->next;
     }
    if (entry) {
      call(entry)
    } 
    else {
     die "No method in class";
    }

No complex hashing function (just %) and simple equality compare.


-- 
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.

Reply via email to