Module instances of global objects share prototypes?

[Thomas Aylott]

Again, couldn't find the answer to this in the archive or wiki…

I've read the Modules/1.1 spec and the note about Secure Modules and much more.

If modules and your main app have different globals and natives…

A String instance from a module will have a different prototype than a String instance in your regular app?

Is this true of all Modules, or only Secure Modules?

Here are the specific tests that I'd like to know the theoretical answer to, based on the CommonJS spec.

http://gist.github.com/268551 Does a string with a modified String.prototype from a module keep its modified prototype?

http://gist.github.com/268553 Does modifying the prototype of String from your main app have any influence over strings from a module?

I guess the equivalent "issue" in the web universe would be loading each module into a different iFrame.

Since each window has its own natives, a String instance from one frame isn't going to share prototypes with a string from another frame.

Thanks.

— Thomas Aylott

   SubtleGradient
   MooTools

[Kevin Dangoor]

On Mon, Jan 4, 2010 at 10:43 AM, Thomas Aylott <tho...@subtlegradient.com> wrote:

Again, couldn't find the answer to this in the archive or wiki…

That's because this behavior is undefined. At present, I would guess that in most CommonJS systems the globals are shared, but that is an implementation detail and is not guaranteed to be the case.

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Kris Kowal]

On Mon, Jan 4, 2010 at 7:43 AM, Thomas Aylott <tho...@subtlegradient.com> wrote:
> Since each window has its own natives, a String instance from one frame
> isn't going to share prototypes with a string from another frame.

In the secure case, there would only need to be one frame for all
secure modules in all secure module systems. That frame would be
locked down with something like MarkM's initSES script.

http://code.google.com/p/es-lab/source/browse/trunk/src/ses/initSES.js

Any code evaluated in that frame would be guaranteed by virtue of
Object.freeze to be unable to communicate with any other code
evaluated in that frame except through capability objects explicitly
passed into that evaluation.

This limits the scope of concern for inter-frame communication between
permissive frames and the single secure frame. In those cases, it is
possible for the "outer" frame to construct primordials *for* the
secure frame with that frame's eval:

let frame = Frame();
let SecureArray = frame.eval("Array");

Kris Kowal

[Thomas Aylott]

If they don't all work the same way then there is a major compatibility issue here.

This needs to be specified in CommonJS. Isn't that the whole point of CommonJS? To unify stuff like this?

This is not an implementation detail. It's a very basic expectation for the environment.

I have stuff to build and I'd like to know how to actually build real stuff for the real world right now. Ideally in a way that won't break 6 weeks from now.

— Thomas Aylott
   SubtleGradient
   MooTools

On Mon, Jan 4, 2010 at 4:30 PM, Kris Kowal <cowber...@gmail.com> wrote:

…

[Wes Garland]

Thomas:

Given that

1) Modules are expected to work in the Browser
2) You can't have multiple instances of the standard classes in a single browser JS context

I think you can reasonably expect the standard classes to work as I have described earlier today.

Do they not work that way anywhere at the moment?

Wes

--

You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Daniel Friesen]

No.
The whole point of CommonJS is to unify things like file access,
sockets, serving out web pages, etc...
CommonJS by name is Common, and if any thing we standardize would
exclude one area of implementation it's not "common" anymore. And that
includes the ability to write modules that can run in secured contexts.
Thus anything that would destroy the ability to run modules in a secure
context is left undefined as an implementation detail.
If you want to rely on an undefined feature, just stick to
implementations that work that way, code won't break, it just won't be
very portable.
Heck, half the code I write relies on JS 1.8 and ES5 features.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Thomas Aylott wrote:
> If they don't all work the same way then there is a major
> compatibility issue here.
> This needs to be specified in CommonJS. Isn't that the whole point of
> CommonJS? To unify stuff like this?
> This is not an implementation detail. It's a very basic expectation
> for the environment.
>
> I have stuff to build and I'd like to know how to actually build real
> stuff for the real world right now. Ideally in a way that won't break
> 6 weeks from now.
>

> � Thomas Aylott

> SubtleGradient
> MooTools
>
>
> On Mon, Jan 4, 2010 at 4:30 PM, Kris Kowal <cowber...@gmail.com

> <mailto:cowber...@gmail.com>> wrote:
>
> �
>

[Thomas Aylott]

Thanks much.

That's very good to hear.

For #2, it is possible to have multiple instances of the standard classes in the same context if you get them from another context. Since you can have multiple contexts. But that is really very very rare.

I don't know of any environments where what you describe doesn't work. But I'm only really familiar with browsers and JSCocoa.

— Thomas Aylott
   SubtleGradient
   MooTools

[Thomas Aylott]

I think in this case leaving it undefined as an implementation detail is just going to cause incompatibilities and problems.

"exclude[ing] one area of implementation" isn't my point. My point is that it's essential to declare exactly what is supported where. At least with the very basics like this.

If you have 1 thing that works two ways, then you actually have 2 things.

You can't have multiple environments that claim to support that one thing but only support it when used in way1 and not in way2.

There should be 2 things specified. Then the implementation can explicitly state which of those two things they support. Then the script authors instantly know that the things they wrote will or will not work.

Perhaps there is need for "CommonJS Modules" & "CommonJS SecureModules".

"Modules" would `require` a script into your current environment with all the same natives like String and Array. It wouldn't be recommended, but would be fully explicitly possible for a module to modify the prototypes of any native.

"SecureModules" however, would `require` a script into a sandboxed environment with all fresh natives. It would then be possible to modify those natives, but it would be explicitly defined that those prototype changes only apply to the fresh natives inside that sandbox and will not effect the global natives.

Having this explicit difference makes it so that any environment could easily state that they support "SecureModules v1.4+" but not "Modules". Or vice-versa.

Perhaps I should make that an "official" proposal.

— Thomas Aylott
   SubtleGradient
   MooTools

[Wes Garland]

Thomas:

Having something like this as "undefined" isn't as big deal as you might think; there are plenty of APIs which define certain behaviours as undefined -- the key is making developers aware of when it's undefined, so they can act accordingly.

On Mon, Jan 4, 2010 at 6:36 PM, Thomas Aylott <obli...@subtlegradient.com> wrote:

Perhaps there is need for "CommonJS Modules" & "CommonJS SecureModules".

This is precisely the state of the union today: we have Secureable Modules, and we have sandboxes which can run them as Secure modules.  The key is that we have yet to define what the sandbox environment looks like. And we have not done that yet because there are significant implementation hurdles.

Wes

[Kevin Dangoor]

On Mon, Jan 4, 2010 at 6:36 PM, Thomas Aylott <obli...@subtlegradient.com> wrote:

I think in this case leaving it undefined as an implementation detail is just going to cause incompatibilities and problems.

To a developer "undefined" means that you cannot count on any specific behavior. If you take advantage of an "undefined" behavior, that means that there's a chance that behavior could break in the future, or break on a different platform. If you don't monkey with the globals, your app will work fine across CommonJS implementations (barring other, unrelated, compatibility issues of course)

[Thomas Aylott]

I think the crux of the issue for me is discoverability.

I've been trying to figure out exactly how all this stuff works practically all day and your short answer here is exactly what I was looking for.

If CommonJS ever does specify how natives relate to modules, I'd like this proposal to help push for keeping these two ways of handling natives with modules  explicitly separate and distinct.

Until then it might be good to explicitly note somewhere that this is undefined and remains so at least until it is explicitly defined.

— Thomas Aylott
   SubtleGradient
   MooTools

[Kevin Dangoor]

On Mon, Jan 4, 2010 at 9:58 PM, Thomas Aylott <obli...@subtlegradient.com> wrote:

I think the crux of the issue for me is discoverability.

I've been trying to figure out exactly how all this stuff works practically all day and your short answer here is exactly what I was looking for.

If CommonJS ever does specify how natives relate to modules, I'd like this proposal to help push for keeping these two ways of handling natives with modules  explicitly separate and distinct.

Until then it might be good to explicitly note somewhere that this is undefined and remains so at least until it is explicitly defined.

Yes, you are right about this. This is an important enough topic that making a note in the spec about the behavior of globals is a good idea.