Re: E patches for review: ELoader, FileGetter

On Mon, 2010-05-24 at 09:51 -0400, Kevin Reid wrote:
> On May 4, 2010, at 11:35, Thomas Leonard wrote:
> > On Tue, 2010-05-04 at 10:20 -0400, Kevin Reid wrote:
> >> Most significantly with regard to the design, we need a system which
> >> allows defining modules in terms of multiple source files which share
> >> *private* state. Right now, any objects which must share private  
> >> state
> >> (e.g. an unsealer) must be defined in the same .emaker (because
> >> anything exported by an emaker is visible to the entire vat), which  
> >> is
> >> a bad situation for writing well-structured code.
> >
> > Can this be handled by creating a top-level .emaker in the module?  
> > e.g.
> >
> > # instance.emaker
> > def sharedState := <this:makeSharedState>()
> > [
> >  "foo" => <this:foo>(sharedState),
> >  "bar" => <this:bar>(sharedState)
> > ]
> >
> > Then to use it:
> >
> > def <instance> := <module:instance>
> > <instance:foo>(...)
> > <instance:bar>(...)
> 
> [Sorry, I forgot to note to reply to this message.]
> 
> The problems with this method are:
> 
>    - <module:instance> is inherently misnamed; the result of a <>  
> expression should not *logically* be a new anything. That should be  
> reserved for things named makeInstance().

Yes, it would have been better style if I'd wrapped it in a function.
Then we'd have:

def <instance> := <module:makeInstance>()

>    - Implementation details are exposed as <module:foo>.

I don't think so. sharedState is a private structure with the
implementation details. The map returned for the module instance only
contains public names ("foo" is public in this example).

>    - There is an indirection exposed to the user that they don't have  
> reason to care about; a client should not have a procedure to load a  
> module differently if it does not happen to have any 'shared  
> concepts'. (I should clarify that I agree that there-are-no- 
> singletons; I just think that the *default* module-loading protocol  
> should permit modules to instantiate shared DeepFrozen objects.

I can think of cases where that would be useful (e.g. interfaces and
guards). I assume such changes would also apply to the regular
ImportLoader (i.e. they're not specific to the modules system)?

What about these though?

# A.emaker
interface foo {}
def x := 0
[x, foo]	# (DeepFrozen)

# B.emaker
interface bar {}
var x := 0
[x, bar]	# (not DeepFrozen)

Will I get a single instance of "foo" each time I import A, but a
different (!=) instance of "bar"?


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk