VM cleanup

Raab, Andreas Andreas.Raab at disney.com
Sat Mar 27 02:59:17 UTC 1999


> I think a naming convention must address the following concerns :
> 
> 1) At the moment, it seems all named primitive method names must be unique
> across all classes, with the possibility of collisions higher than the
> normal case with Smalltalk.  I'm not sure if there is a collision between
> names across modules.
> 
At the moment there isn't - the function looked up is only searched in the
given module. There is, however, a potential collision problem when stuff
gets simply put into the VM itself and not into separate modules but I don't
consider this to be a really big problem. The current naming convention for
most of the primitives is 'primitiveSubsystemAction' (e.g.,
primitiveMIDIPortOpen, primitiveAsyncFileClose, primitiveSocketError) and to
me this looks pretty sufficient.

>  This is a side effect of the C translation - there's
> really no reason why the class name can't be prepended to the method name.
> 
The class name can of course be prepended to the primitive name - it may
however be confusing at certain points since the same primitive may be
invoked from different classes. And ... it's more stuff to type ;->

> 2) There should be a way to handle the named primitive call where some VMs
> have them external, and others internal, with the Smalltalk code glue
> indifferent.  As I understand the Mac code, the search is done in either
> one or the other depending upon the call.  It seems like a minor fix to
> have the function searched in the supplied module name, then in the VM on
> failure. This would also allow the overriding of malfunctioning or
> "in-the-process-of-enhancement" primitives. Currently, moving the Balloon
> classes to an external module requires modification all of the primitive
> calls.
> 
There are two problems with the approach: 
#1: If you have a brand-new VM and an older plugin you would actually use
the old stuff rather than the newer, VM-builtin versions. Given that plugins
may not only be in the image or VM directory this could cause a lot of
*very* confusing problems.

#2: Assume your VM contains an older Plugin version. You start your image
and notice that something goes wrong (the ST code requires the newer
version). If you then get the newest plugin and drop it into your VM
directory you'll mixup calls to outdated internal primitives (basically all
the ones you did before you dropped the Plugin in there) with newer external
ones. If (such as in the balloon case) these primitives require certain
behavior of a set of primitives you may get a really nice crash here. 

Later on, you may have an updated VM which now contains the newest version
and you'll get the same problem just the other way around (e.g., using older
external versions and newer internal versions).

> 3) Mac people in particular might be turned off to the Squeak directory
> containing piles of plug-ins - there should also be a
> (platform-dependent?)
> convention for collecting plug-ins that will be searched for.
> 
On Unix/Win32 there are conventions for finding these DSOs/DLLs even if they
are not in your Squeak directory - which is part of the above mentioned
problems ;-(

  Andreas

--
PLEASE NOTE NEW EMAIL ADRESS!

+===== Andreas Raab ========= (andreasr at wdi.disney.com) ==+
| Walt Disney Imagineering        Phone: +1 818 544 5016  I
I Glendale, CA                    Fax:   +1 818 544 4544  I
+======< http://isgwww.cs.uni-magdeburg.de/~raab >========+





More information about the Squeak-dev mailing list