I think a naming convention must address the following concerns :
- 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 ;->
- 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).
- 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@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 >========+