Re: simple modules

On Tue, Feb 2, 2010 at 1:39 AM, Sam Tobin-Hochstadt wrote: > Whatever we come up with for modules would be a good way to structure > all of the potential additions in Harmony - ArrayBuffers, Proxies, etc. Yes: for powerless code, that I do agree with. Ihab -- Ihab A.B. Awad, Palo Alto, CA

Re: simple modules

On Tue, Feb 2, 2010 at 1:28 AM, Kevin Curtis wrote: > Just a final point - modules that are imported with 'import' can be native > modules? Yes. As long as the module does not provide powers, i.e., it is just equivalent to code, it can be provided ambiently as a module. > There has been discuss

Re: simple modules

On Mon, Feb 1, 2010 at 11:13 PM, David Herman wrote: > ... (specifically: "contexts are the means by which access to platform > resources are mediated" -- yes). > Creating new contexts would make it possible to restrict what modules can be > imported, so you could > create "pure" execution conte

Re: simple modules

On Mon, Feb 1, 2010 at 11:01 PM, Brendan Eich wrote: > Ihab talked about it on the list: > http://old.nabble.com/Native-modules-td27231395.html Strawman sent. Ihab -- Ihab A.B. Awad, Palo Alto, CA ___ es-discuss mailing list es-discuss@mozilla.org ht

Re: simple modules

Hi Kevin, On Mon, Feb 1, 2010 at 10:46 PM, Kevin Curtis wrote: > A service registry sounds interesting. Is there a proposal out there (in > this group or elsewhere) dealing with how/where authority to platform > objects or object capabilities are dished out. I made up a strawman here: http://

Re: simple modules

On Tue, Feb 2, 2010 at 9:20 AM, Sam Tobin-Hochstadt wrote: > I'm confused about the problem here. See previous; hope that clarifies. > Here is where I think there's an important difference between the > style of isolation you want for different modules in the same software > product (maybe both

Re: simple modules

On Mon, Feb 1, 2010 at 10:09 PM, Allen Wirfs-Brock wrote: >>   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 o

Re: simple modules

Another clarification: On Tue, Feb 2, 2010 at 3:17 AM, wrote: > Assume I am the code of a module, by the 2nd-class proposal ... In this example, what I'm saying is that "I" am coding a module that says: import "fs" as fs; /* now create one or more objects with limited authority */ Ihab -

Re: simple modules

On Mon, Feb 1, 2010 at 10:20 PM, Brendan Eich wrote: > On Feb 1, 2010, at 1:48 PM, ihab.a...@gmail.com wrote: >> "Giving access to all of the things I have access to" is >> _the_ problem that leads to excess authority, the separation of >> designation from authorization assuming ambient authority

Re: simple modules

2010/2/2 David Herman > Hi Vassily, thanks for the feedback. > > > It should be > > > > > > > > // import everything as Math > > import "Math"; > > > > alert("2π = " + Math.sum(Math.pi, Math.pi)); > > > > > > This is already possible with the `import "Math" as Math' form (which > incidentally c

Re: simple modules

I forgot to include my footnote! On Tue, Feb 2, 2010 at 2:39 AM, wrote: > ... the 2nd class [*] proposal ... [*] - The name "2nd class" is something of a convenience for the moment. Whether modules are 1st or 2nd class is a downstream thing we can talk about later; there are both 1st and 2nd cl

Re: simple modules

On Mon, Feb 1, 2010 at 10:09 PM, Allen Wirfs-Brock 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 f

Feedback on proxies and alternative API discussion

Hi, Last week at the TC39 meeting, we had a constructive discussion about proxies (a.k.a. catch-alls). I summarized the feedback received by the committee in a separate "Feedback" section: Several committee members wanted to know w

Re: simple modules

Thanks. I can see how it hangs together now. Whatever we come up with for modules would be a good way to structure > all of the potential additions in Harmony - ArrayBuffers, Proxies, > etc. > -- > sam th > sa...@ccs.neu.edu > Also for new HTML5 functionality. Furthermore, browser vendors could p

Re: simple modules

On Mon, Feb 1, 2010 at 8:28 PM, Kevin Curtis wrote: > On Mon, Feb 1, 2010 at 11:13 PM, David Herman  wrote: >> >> In terms of mechanism, that's not exactly what I had in mind, but in terms >> of purpose that's the rough idea (specifically: "contexts are the means by >> which access to platform res

Re: simple modules

On Mon, Feb 1, 2010 at 11:13 PM, David Herman wrote: > In terms of mechanism, that's not exactly what I had in mind, but in terms > of purpose that's the rough idea (specifically: "contexts are the means by > which access to platform resources are mediated" -- yes). Creating new > contexts would

Re: simple modules

> Sounds good. A Context is configured with the objects (eg dom, xhr) that the > developer wants to make accessible in the Context. These objects are bound to > an outer lexical frame which all modules imported into the Context can > access. Contexts are the means by which access to platform res

Re: simple modules

On Feb 1, 2010, at 2:46 PM, Kevin Curtis wrote: A service registry sounds interesting. Is there a proposal out there (in this group or elsewhere) dealing with how/where authority to platform objects or object capabilities are dished out. Ihab talked about it on the list: http://old.nabble.

Re: simple modules

On Mon, Feb 1, 2010 at 9:08 PM, Brendan Eich wrote: In either module system approach, first-class or second-class, nothing > prevents a module from conveying authority, which may be unwanted or even > hazardous. Zero-authority modules and a service registry are as far as I can > tell advisory, no

Re: simple modules

On Feb 1, 2010, at 2:20 PM, Brendan Eich wrote: The problem is not defending the integrity of X, Y and Z. The problem is this: import X as ...; In the proposal, the ... is the name of a first-class object you can use to reference exports from X. If X exports f1 this form does *not* bind

Re: simple modules

On Mon, Feb 1, 2010 at 4:48 PM, wrote: > On Mon, Feb 1, 2010 at 9:21 AM, Sam Tobin-Hochstadt wrote: >> That's only the case if X, Y, and Z provide access to their internal >> state via the bindings they export. > > The problem is not defending the integrity of X, Y and Z. The problem is this: >

Re: simple modules

On Feb 1, 2010, at 1:48 PM, ihab.a...@gmail.com wrote: On Mon, Feb 1, 2010 at 9:21 AM, Sam Tobin-Hochstadt wrote: That's only the case if X, Y, and Z provide access to their internal state via the bindings they export. The problem is not defending the integrity of X, Y and Z. The problem

RE: simple modules

> -Original Message- > From: ihab.a...@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 auth

Re: simple modules

On Mon, Feb 1, 2010 at 1:08 PM, Brendan Eich wrote: > It's important to note again that the second-class proposal relies on > lexical scope for isolation. Importing all exports imports static bindings > with error on conflict, and you can selectively import (with renaming) if > you want to control

Re: simple modules

On Mon, Feb 1, 2010 at 9:21 AM, Sam Tobin-Hochstadt wrote: > That's only the case if X, Y, and Z provide access to their internal > state via the bindings they export. The problem is not defending the integrity of X, Y and Z. The problem is this: import X as ...; import Y as ...; function

Re: simple modules

On Feb 1, 2010, at 9:55 AM, Kevin Curtis wrote: Suppose - maybe unlikely - the client platform webcam is exposed to ECMAScript in a HTML5 webapp. The whole issue of webcam API security is important, but not in es- discuss, and not tied to module systems. I dread the w3c pushing an access-c

Re: simple modules

Suppose - maybe unlikely - the client platform webcam is exposed to ECMAScript in a HTML5 webapp. How would this be accessed in a module system: import modwebcam; // what is this? native code? do i have access to it? via a container/context/global object? import JSON; // is this native code? How

Re: simple modules

On Feb 1, 2010, at 9:21 AM, Sam Tobin-Hochstadt wrote: On Mon, Feb 1, 2010 at 1:04 AM, wrote: But, in some module M that imports X, Y and Z, the top-level lexical environment *must* include access to all the state encapsulated by X, Y and Z. That's only the case if X, Y, and Z provide access

Re: simple modules

On Mon, Feb 1, 2010 at 1:04 AM, wrote: > > Hi Sam, > > On Sun, Jan 31, 2010 at 6:56 PM, Sam Tobin-Hochstadt > wrote: > > First, it's also possible to achieve isolation via lexical scope by > > using functions, closures, and objects, as Dave's example shows.  Our > > proposal attempts to leverage

Re: simple modules

Hi Vassily, thanks for the feedback. > It should be > > > > // import everything as Math > import "Math"; > > alert("2π = " + Math.sum(Math.pi, Math.pi)); > > This is already possible with the `import "Math" as Math' form (which incidentally can easily be compiled to be exactly as efficien

Re: simple modules

Small feedback from users. This example does not look right. // import everything import "Math"; alert("2π = " + sum(pi, pi)); It should be // import everything as Math import "Math"; alert("2π = " + Math.sum(Math.pi, Math.pi)); We already have "with" for polluting local namespace, and sh