Re: E patches for review: ELoader, FileGetter
Kevin Reid <kpreid-M/[email protected]>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
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(). - 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/>