Allen_Wirfs-Brock at mail.instantiations.com  wrote...

>In Henrik's proposal, that code would exist in a module (let's call it module X) that presumably would have to have an import statement something like:
>        self uses: #(SqueakTranscriptModule) "I don't really understand the syntax, it doesn't matter"
>in order to make the global, Transcript, available for use from the module.  The problem, is that as soon as you do this you have constrained Module X to only be used in conjunction with SqueakTranscriptModule.  If there were others modules that implemented and exported Transcript (let's say a LoggingTranscriptModule or a RemoteTranscriptModule) Module X could not make use of them.  So, with this scheme we have lost flexibility in the use (or reuse) of Module X but we have gained a degree of confidence in the correctness of our program because we are ensured that Transcript is being defined by the module that we intended (as presumably tested against).
>
>In Team/V we tried to solve this problem by using two orthogonal artifacts: packages and clusters...
>
>I've though a bit about, how this issue might be resolved in the context of Henrik's proposal. The first thing that comes to mind is to (optionally?) separate the actual code part of his module into a separate entity (a package?).  Then the module would provide all the structure information but the package could still be used independently to create modules with alternative structuring.

I will admit to little experience with these issues.  However, I did give this aspect some thought in the Environments design.  This approach compiles the statement

	Transcript show: "my message";cr;
as
	TranscriptModule Transcript show: "my message";cr;

where #Transcript is a message sent to whatever module is bound to the (real) global, TranscriptModule.  The idea is that several Transcript packages can be resident at the same time.

Then, just as you can now rebind a global, as in

	Changes := ChangeSet new

you could similarly rebind a module, as in

	TranscriptModule := ScreenTranscriptModule
or
	TranscriptModule := RemoteTranscriptModule

This can happen in the twinkling of an eye, and it can be undone by various error handlers during experimentation, because the original foreign reference just sends a message.

So I think there is an answer to this need in the simple approach.  It may not do everything Team/V does, but it seems to handle this particular need.

	- Dan

--