This is perhaps a good place to explain a few possible strategies for
using classes and vmplugins to handle platform spread.

Currently all the vmplugins are generated the same on all supporting
platforms. Thus they have the same api and the platform must provide
suitable code (even if it is a clean failure) for every interface. The
ST code the assumes the exact same behaviour (probably a really bad
idea in systems with crappy documentation like too many prims!) and we
hope all goes well. To an astonishing extent, it does. Just not always.

However there is no need for vmplugins to be the same. Nothing prevents
us from having platform specific apis in platform specific vmplugins.
We would then need platform specific classes that use
fooble
<primitive: 'yeehaw' module: 'BeOScountryMusicPlugin'>
etc to access those prims. That's one very simple approach. We could
have a platform spread of filestream classes with each one handling all
the prims via similar calls.

VMMaker was designed to handle such things in a variety of ways. Simply
not having the support directory for BeOScountryMusicPlugin in the tree
for win32 would stop it being generated for windows. Another approach
is to use the method #moduleName to make the BeOScountryMusicPlugin
class generate code for a plugin named CountryMusicPlugin. We would
also use the #shouldBeTranslated protocol to make sure the proper
plugin class was used. Note that BeOScountryMusicPlugin need not be a
subclass of CountryMusicPlugin for this to work. If this technique is
used then all the platform classes would simply refer to 
fooble
<primitive: 'yeehaw' module: 'CountryMusicPlugin'>
which means that they could inherit the stadard set but still add their
own extras. It also means not having to explain to users about
differently named vmplugins in documentation. (What, we have
documentation?)

So, attempting to pull this all together, we can provide a plain stdio
type vmplugin with a class that uses it (as now) as well as other
classes of file stream that use quite different apis. It's all in the
bridge pattern and the cleverness of VMMaker.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Oxymorons: Religious tolerance