Re: E patches for review: ELoader, FileGetter

On May 24, 2010, at 11:10, Thomas Leonard wrote:
> On Mon, 2010-05-24 at 09:51 -0400, Kevin Reid wrote:
>>   - <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>()

Yes. The 'irrelevant indirection' objection applies even more so to  
this, though.

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

I'm not talking about the sharedState, but the implementation code,  
which you named <this:foo> and <this:bar>. It should not be public  
unless it is part of the public interface (which is reasonable, but  
should not be obligatory).

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

We want a module system that replaces ImportLoader.

> 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"?

As it currently stands, if it were not for the fact that foo and bar  
are not actually DeepFrozen, the answer is yes.

I think the right answer here is that all elements of a module  
(<someloader:B>) should be evaluated at-most-once and required to be  
DeepFrozen, unless explicitly specified to act otherwise (either in  
metadata or metacode).

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>