Re: E patches for review: ELoader, FileGetter

On May 4, 2010, at 7:14, Thomas Leonard wrote:

> I've committed the SecureRandom change now. Next up:
>
>
> Allow uncalling deep and shallow ReadyOnlyFile objects:
>
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/b17bc51fe586b6eabcedfe4d46da5b0a65b65428

Code looks good, except that I would make the method something less  
generic than "isTransitive"; it should be a name which is  
appropriately specific within the context of the overall File  
protocol. Perhaps it should be a 3-valued return, distinguishing read/ 
write and shallow and deep read-only? I haven't looked to see if there  
is any existing interface covering RW/RO.

Also, please add *specification* text to wiki.erights.org (following  
the existing examples of documents in <http://wiki.erights.org/wiki/Category:E_specification 
 >, and using the appropriate templates) for anything you add to the  
public interfaces of core E objects.

> ELoader:
>
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/ae8f337328aa0bbbf5d9a9cb565866fe3fff975d
>
> http://www.eros-os.org/pipermail/e-lang/2010-February/013416.html
>
> ELoader now provides an __optUncall and, just to make it obvious that
> envExtra isn't private, there's an explicit getEnvExtras/0 too. This
> should make it easier to spawn new vats with the same set of modules,
> but I haven't updated seedVat yet.

I object to including ELoader in E-on-Java because it does not go far  
enough.

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.

In general, there should be a separation between "what are the  
'exported symbols' of this module" and how they are laid out on disk  
-- *optionally*. The default should be to map symbols to files because  
that is convenient, but other structures should be possible.

Other features which are desirable in a module system, but can  
probably be added later, are references to (dependencies on) other  
modules, 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.)

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