On Tue, Feb 2, 2010 at 3:12 PM, <ihab.a...@gmail.com> wrote:
> On Tue, Feb 2, 2010 at 7:24 PM, Brendan Eich <bren...@mozilla.com> wrote:
>> On the other hand, the second class "simple modules" proposal, plus the
>> impending Context proposal, allows A and subset-A, as far as I can tell.
>
> Yes, it allows subset-A by the creation of new Contexts.
New Contexts are necessary only in the case where there are some
stateful modules whose access needs to be restricted. Note also that
new Contexts are also necessary for programming in an ocap manner in
the primordials module system strawman as demoed by Kris at the most
recent TC39 meeting. For example, I think he showed an example like
this:
var FS = require("fs");
FS.open("myfile");
Here we again have a global namespace, giving access to powerful,
stateful code, accessed by the `require' function, which is
potentially restricted by using a Context to change the behavior of
`require'. (If I've misunderstood what the code Kris presented did,
please let me know.)
The alternative is to pass all state explicitly. This is (I think)
what the Emaker-style proposal does. This has the following important
drawbacks:
1. It means that the *only* way to program modularly is to use the
stateful-object-passing style. Since this is less convenient for many
use cases than simply mutating the global object as in current ES,
programmers are less likely to use modules.
2. If we persuade programmers to use modules, they're likely to pass
around overly-powerful objects, making reasoning about security
harder. A module which takes a single parameter named 'global' and
performs all its operations by mutating this object is much harder to
reason about than one which imports numerous modules, a few of which
are stateful.
> The result is not a "capability language" as commonly understood; the
> language constructs by themselves are not _prima facie_ usable to
> implement ocaps. The result is rather more akin to a capability
> operating system, in which somewhat coarse-grained units of trust
> share information freely among themselves, while having limited
> authority at their boundaries.
>
> If TC39 wishes to construct such a system in lieu of a capability
> *language* in SES, the committee needs to achieve concensus on this
> issue first -- and update the wiki! -- before commissioning module
> proposals.
I'm surprised that you don't think this qualifies as a capability
language. ES + the simple modules proposal seems to me to be just as
much a capability language as the language and module system in
Jonathan Rees' dissertation.
--
sam th
sa...@ccs.neu.edu
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
