Hello Gaby, Gabriel Dos Reis <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
