Re: [Axiom-developer] Spad and its object model

[Stephen Wilson]

Hello Gaby,

Gabriel Dos Reis <address@hidden> writes:
[...]
>   However, I do believe the use of arrays has inherent problems in 
> terms of maintaining coherence of function pointers assigned to slots.
> Because the mapping from declarations order to integer has lost important
> informations (name, types, etc) of the functions being mapped.

Im not sure if this is fundamental to an array.  I think it is
entierly possible to define vtable elements at a fixed offset which
provide alternative methods of indexing.  Indeed, I belive the current
layout provides such a rudimentary facility of mapping export labels
to arity and argument type information, but the details escape me (Its
been a long time since I looked at this.  I recall making notes.  I
need to do some digging).

>   I would like to suggest the idea of using hastables as opposed to
> arrays to implement vtables (materialization of domains and packages).
> Not only it would help tame the problem of coherence, but also move
> to functionalities like "post facto extensions".

Roughly, what are the keys?  What do the entries look like?

I assume "post facto extensions" motivate the choice of a hash as they
are easily extensible (new elements are readily added).  Could we not
simply make vtable vectors expressly adjustable?

I would need a clear picture of what the semantics would be for "post
facto extensions".  Do you sugest following Aldor explicitly? IIRC new
exports introduced by `extend' are not visible to previous
definitions, except via `has' predicates which execute during
runtime.  Are there other issues involved?

Thanks,
Steve