Andrew,

Just to confirm this, your view of the situation is entirely correct. The
primitive should just silently fail if either the shared library or the
entry point is not found.

  Andreas
--
+===== 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 >========+


> ----------
> From: 	Andrew C. Greenberg
> Reply To: 	squeak at cs.uiuc.edu
> Sent: 	Monday, October 25, 1999 5:11 AM
> To: 	squeak at cs.uiuc.edu
> Cc: 	recipient list not shown
> Subject: 	Re: Problems with OSAPlugin in NON-Mac OSes
> 
> >Andrew,
> >I guess you are right. The primitive should fail without any error
> >message, and I'll modify that right now in the OS/2 VM.
> 
> I think that's the correct solution.
> 
> >In case the changeset you sent gets into the standard release image I
> >will put the error message again.
> 
> I would not put the error message back again, even if the Appletalk 
> stuff were purged from the system entirely,
> 
> I believe the proper semantics for failing to find a .DLL or shared 
> library is for the primitive to fail silently, so that the Smlltalk 
> code can decide what to do.  There are several reasons for this:
> 
> 	1)  One of the excellent features of Squeak is that a plugin 
> can be built and tested to run in Squeak, long before any translation 
> or compilation takes place.  The typical setup for a primitive (at 
> least during development) is to code something like:
> 
> 	foo: aParmObject with: anotherParmObject
> 
> 		<primitive:'primFoo' module: 'FooPlugin'>
> 		^FooPlugin
> 			doPrimitive: 'primFoo:with:'
> 			withArguments: {aParmObject. anotherParmObject}
> 
> which code will, if the first execution of a FooPlugin primitive 
> call, will check to see if FooPlugin is present, and if primFoo is in 
> FooPlugin.
> 
> 
> 	If unsuccessful, the primitive will "fail," executing 
> FooPlugin>>doPrimitive:withArguments:, thereby simulating the plugin 
> on the parameters.
> 
> 	If successful, the primitive will be called.
> 
> In this way, the programmer can develop his primitive almost 
> exclusively in the Squeak environment (except to the extent the 
> plugin is making systems calls).
> 
> 	2)  You may wish to maintain a separate machine independent 
> version of the code, precisely so that the functionality can be 
> present across all platforms, but speeded up (substantially) when the 
> local plugin is made available.
> 
> Ideally, the Plugin (and any code that relies upon the plugin) will 
> recognize and gracefully cater to the possibility that the DLL may 
> not be present.  I am presently looking at various ways to build such 
> bulletproofing into the plugin building system.
>