simple modules

[Allen Wirfs-Brock]

> -----Original Message-----
> From: ihab.awad at gmail.com
...
> 
> The problem is not defending the integrity of X, Y and Z. The problem
> is this:
> 
>   import X as ...;
>   import Y as ...;
> 
>   function f1() { /* operate on the authorities of 'X' */ }
>   function f2() { /* operate on the authorities of 'Y' */ }
> 
> In this fashion, I cannot limit, via lexical scope, that f1 operates
> on X but not Y, and that f2 operates on Y but not X.
> 

But the above four lines are all in the same module, that is in the same unit of source code.  As the author of this module you control what you put into the bodies of both f1 and f2 so you are perfectly free to restrict what you put into either.  If you don't trust yourself, then create separate modules for f1 and f2 that only import X or Y and not both.
...
> there is the goal:
> 
>   "Support a statically verifiable, object-capability secure subset."
> 
> How does your proposal subset down this way?

It seems to me that the 2nd class module proposal is all about: 

"Be a better language for writing:
    complex applications;
    libraries (possibly including the DOM) shared by those applications;"

rather than an "object-capability secure subset."

They are about dividing up the source code of complex application and library into manageable units that easily integrate together in a way that avoids unintended naming clashes.  This is completely orthogonal to objects as capabilities or any other dynamic properties of programs.

Allen