plugin suffix

Bert Freudenberg bert at isg.cs.uni-magdeburg.de
Sun May 13 09:40:33 UTC 2001


On Fri, 11 May 2001, phiho.hoang wrote:

>     I also suggested that we have a second look at the way the named
> primitive mechanism is looking up the name for builtin primitives. Why can't
> we consider the executable as another module housing the internal primitives
> and treat internal/external primitives the same way (this is only do-able
> for systems that support shared objects and equivalents).

Sounds good. That is, as long as there still is the possibility of
ecternal modules overriding the internal versions.

It was also discussed a while ago that it would be cleaner and better
security-wise to not use dynamic name lookup for the plugin functions but
only for the pre-defined functions (setInterp, getName etc.), and have
each module advertise a table of all its functions and addresses. The
problem is that on various platforms it is not easy to limit the range of
exported functions (like, all C runtime functions are accessible). It
would also give some level of reflectivity wich is a Good Thing ;-)

So, if now is the time to overhaul the module stuff that could be included
as well. I'd say it would even eliminate the whole namespace problem
because no function names except for the "housekeeping" functions would
have to be exported at all.

-- Bert





More information about the Squeak-dev mailing list