...

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.

Fair enough - it looks like there is indeed an ad hoc naming convention in place then.

...

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 ;->

Agreed - but then again the previous discussion on naming conventions does pretty much the same thing, just in a different way. It seems that the amount of typing is constant - instead of the class name, it's the subsystem name.

...

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).

I agree version control of plug-ins is an issue that gets opened up with the whole idea of named external primitives, but I believe making this rather minor change doesn't make the problem significantly worse, and gives the additional benefit of playing around with normally VM-hosted primitives without the overhead of rebuilding the VM. I'm arguing this mainly as a convenience for the plug-in developer, who I think represents a small part of the Squeak community.

For the rest of the Squeak community, I think pushing a lot of the current primitive stuff out allows people to make stripped down images with correspondingly stripped down VMs without resorting to recompilation of the VM - you just remove the unreferenced DLLs.

Philosophically, I guess it needs to be decided whether or not it's better to have everything lumped into an increasingly complex VM with little danger of version control problems, or to modularize the system and live with some potential maintenance issues.

...

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 ;-(

It believe the same is true for the Mac - local directory, then System Folder:Extensions, then System Folder (aka Poor Man's Search Path). None of these is particularly convenient. The addition of a search in a local "Plug-ins" folder, such as done by Photoshop or Navigator, might be more tidy.

=================================================== Duane Maxwell dmaxwell (at) launchpados.com CTO http://www.launchpados.com Launchpad, Inc. (619) 578-8500 x226

Information contained herein is my personal opinion and not necessarily that of Launchpad, Inc. ===================================================