Ian Piumarta <Ian.Piumarta at inria.fr> wrote:
> > Surely, simply using the table in sqNamedPrimitives.h in the way it is
> > intended to be used will do this?
> 
> I've done nothing to the the way sqNamedPrims works.  For internal
> prims, the lookup is identical to all the other platforms.
> 
> > The lookup for internal named prims is done _only_ via the
> > table. Since 'exit' is not in the table, it can't be wrongly
> > called. Scratch one dumb way to shoot oneself in the foot. No
> > worries.
> 
> But the "problem" occurs when looking in an external module, not an
> internal one.  When dlsym() looks up a symbol it searches in the named
> .so and then in the global namespace.  There is a flag in one of the
> Unix standards definitions somewhere called RTLD_LOCAL that can be
> `or'ed with the dlopen() "mode" argument to cause subsequent dlsym()s
> to look only in the .so itself, and never in the global namespace.
> But I don't know how portable this is.

I'm not into all details of this but consider the following:

Instead of having one central table that can be used in a portable way
to find things, distribute this table so each module has its part of the
table. The only thing that should be linked when loading a module is
this table. Everything else, that is the real content, is fetched throw
this table. I have used such a scheme for a long time and find it very
good. It is possible to associate explicit types with each
method/function that can make it easy to call things in a coherent way.
The Python folks are using a scheme similar to this I believe.

In such a module everything is static (= local) except the table.

Another twist is to fix numbers for each primitive within the module
with an "enum" and then, having a Squeak representation of the same enum,
it becomes possible to use array access directly, narrowing the gap
between oldtime numbered primitives with the newer named ones.

I am going to look into these kinds of things in the near future and
will have more to say.

/Mats