[e-lang] E patches for review: ELoader, FileGetter
kpreid at switchb.org
Mon May 24 06:51:35 PDT 2010
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
>> (e.g. an unsealer) must be defined in the same .emaker (because
>> anything exported by an emaker is visible to the entire vat), which
>> a bad situation for writing well-structured code.
> Can this be handled by creating a top-level .emaker in the module?
> # instance.emaker
> def sharedState := <this:makeSharedState>()
> "foo" => <this:foo>(sharedState),
> "bar" => <this:bar>(sharedState)
> Then to use it:
> def <instance> := <module:instance>
[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().
- Implementation details are exposed as <module:foo>.
- 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.
>> and metadata including the version of the safeEnv (or
>> whatever) the code in the module expects to be evaluated in. (This is
>> so that we can in the future safely revise the E design in ways
>> including deleting now-seen-as-clutter safeEnv members.)
> Would be nice. Couldn't the version pragma do this though?
The version pragma is strictly syntactic; it is gone after parsing.
Kevin Reid <http://switchb.org/kpreid/>
More information about the e-lang