simple modules

[ihab.awad at gmail.com]

On Mon, Feb 1, 2010 at 10:09 PM, Allen Wirfs-Brock
<Allen.Wirfs-Brock at microsoft.com> wrote:
> If you don't trust yourself, then create separate modules for f1 and f2 that only import
> X or Y and not both.

Ok, that's a good solution.

> 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."

If a module proposal were unable to support the latter, then this
should be a serious disadvantage, given that an ocap secure subset is
a stated goal of ES-Harmony.

If the proposal's only way of supporting an ocap secure subset is to
say, "don't use modules", or some other exhortation to wade into the
Turing tarpit, then that should also be a serious disadvantage.

Let me illustrate by describing how, as I see it, I would have to
program with the 2nd class [*] proposal in order to partition
authority in a fine-grained manner:

1. I would have to create a new Context each time I wish to create a
subset of my running objects having only a clear subset of my
authority.

2. I would not have the benefits of the static analysis, so I would
have to use some function that wraps around the proposed loadModule
function. These benefits I would relinquish would be:

(a) My code would no longer have the performance benefits of having
several modules linked and sent to the use site together by some
assembly tool; and

(b) My code would be complicated by the need or asynchronous access to
the results of the loaded modules.

This means that:

    var point = (import 'point')({ x: 3, y: 4 })
    /* export service based on 'point' */

becomes:

    /* declare promise to service based on 'point' */
    makeNewContext('point', { x: 3, y: 4 }, function(thePoint) {
      /* fulfil promise to service based on 'point' */
    });
    /* export promise to service based on 'point' */

> 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.

The static properties of programs are *the* way we arrange to reason
about the dynamic properties of the object graph induced by the
programs. As I note above, in patterns of use pursuant to the ocap
paradigm, the lexical structure is definitely *not* by any means
orthogonal to the dynamic flow of authority.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA