tc39 / proposal-shadowrealm

ECMAScript Proposal, specs, and reference implementation for Realms
https://tc39.es/proposal-shadowrealm/
1.44k stars 67 forks source link

Official name bikeshed #321

Closed syg closed 3 years ago

syg commented 3 years ago

With Realms at Stage 3, let's have an earnest bikeshedding discussion on the name "Realm". We've talked about renaming it many times in the past but AFAICT never had the earnest discussion. The shape of the current proposal has deviated sufficiently from long-standing uses of "Realm" in ecma262 and HTML that a different name seems more appropriate.

At the July TC39, we have consensus that the major JS vendors (browsers + node) will hold off shipping (but not implementing!) until we've bikeshedded.

ljharb commented 3 years ago

Of the ones i've heard tossed around so far, "CallableBoundary" seems the most apt.

Jack-Works commented 3 years ago

Isolate 🤣

syg commented 3 years ago

Isolate

Hard pass. :)

guybedford commented 3 years ago

I wonder if Membrane makes sense?

syg commented 3 years ago

I wonder if Membrane makes sense?

Also no IMO, because it is not really a membrane in the technical sense. So far I also think CallableBoundary is the most accurate.

mhofman commented 3 years ago

CallableBoundary is a bit of a mouthful for a user visible API. It also doesn't capture the fact you get a whole new set of intrinsics and that module instances are not shared.

Context like Isolate is a very overloaded term. I unfortunately don't have any better ideas that come to mind.

ljharb commented 3 years ago

a bit of a mouthful for a user visible API

SharedArrayBuffer and FinalizationRegistry would like to have a word with you :-p

kriskowal commented 3 years ago

Riffing: Intrinsics (new Intrinsics()), ParallelRealm, ThroughTheLookingGlass (LookingGlass, Glass, certainly not Window).

I still like Realm. It fits the bill and the probability of another first-class API appearing that would be a stronger contender for the name is unlikely. It’s far more likely that we’d parameterize the existing Realm constructor for variations on the theme. That there are multiple internal names fit the bill doesn’t condemn the public name, and some of those internal things might be factored differently in the future anyway, as we decompose the notion of a worker/page/agent which consists of a realm (for intrinsics) which consists of a compartment (for module graphs).

leobalter commented 3 years ago

From all the previous name bikesheds I've seen about Realms, CallableBoundary doesn't seen bad.

If we want something even more accurate I'd say CallableBoundaryRealm would be better, but only in this aspect. CallableBoundary translates well what this API does.

I'm in favor of this name because it's also very specific to this API and this is very helpful for users to search and find related documentation without noise.

The closest concept name I'd think would be an Acrylic Glove Box, and I hoped for it to have a specific single name, maybe in German.

I'd like to register one of the concerns for this name is the confusion of other things sharing the name in the HTML spec reality. This creates confusion there and implementation. @syg might correct me if I said anything wrong. IMO, this is a compelling argument and I'm fine with a distinct name.

I'll have a PR-draft open to make sure I capture all the parts that would need to be renamed. Maybe seeing it from a rendered spec would make it easier to digest.

kriskowal commented 3 years ago

The closest concept name I'd think would be an Acrylic Glove Box, and I hoped for it to have a specific single name, maybe in German.

You win this round @leobalter. Do we camel case with a hump for every composite of a compound German word likeAcrylHandSchuhFach?

Jack-Works commented 3 years ago

IsolateRealm?

ljharb commented 3 years ago

I still think using "isolate" as a noun, instead of a verb, is very weird.

Jack-Works commented 3 years ago

I still think using "isolate" as a noun, instead of a verb, is very weird.

Then IsolatedRealm

leobalter commented 3 years ago

I believe Isolated or any derivation won't be successful as some delegates don't see this API as full isolation set.

The problem for the naming here is that every name we pick will have objections against.

I'm not kidding that we need to pick the least offensive name.

caridy commented 3 years ago

The prior art is "Context", which is available in node, jscore/ios and v8/android. Creating a new Context(), or new CallableContext() reads well IMO.

ljharb commented 3 years ago

"Context" is way too overloaded a term (think scope) - i'm pretty strongly opposed to that.

Jamesernator commented 3 years ago

My feeling is that names like CallableBoundary doesn't desribe the core functionality of a new "Realm" which is a set of intrinsics/builtin/global. The callable boundary aspect is more of an interface.

Perhaps something like GlobalScope/GlobalEnvironment/FreshBuiltins, admittedly I like none of these extra words like Scope/Environment/Fresh but perhaps there's a more fitting word.

This kind of naming makes more sense with the methods, e.g. globalEnvironment.evaluate(script) can be read as evaluate the script script in the global environment globalEnvironment. (Names like CallableBoundary don't make as much sense, e.g. you wouldn't evaluate a script IN a "callable boundary", the boundary is only the thing that separates the global scopes).

ljharb commented 3 years ago

Since it doesn't provide an actual global object/globalThis, or a container of intrinsics/builtins/etc, then the name shouldn't imply that.

Jamesernator commented 3 years ago

Since it doesn't provide an actual global object/globalThis, or a container of intrinsics/builtins/etc, then the name shouldn't imply that.

But that's exactly what it does, it's just that you can't interact with it except through the evaluate/import methods. The fact the global scope isn't directly accessible doesn't mean it isn't there. And in fact, with a membrane you can almost directly interact with it as if they were just another set of intrinsics.

Jack-Works commented 3 years ago

Maybe Realm is good enough

ljharb commented 3 years ago

Sure, but this isn’t a membrane, and this thing isn’t actually the thing you’re interacting with - it’s still just a screen even if i can use it to remotely view and interact with another place :-)

erights commented 3 years ago

I agree with @Jack-Works that just Realm is fine. It's not like the current exposed realms of iframes or vm.createContext are already widely known as realms, so I don't think calling this new thing Realm would be confusing.

ljharb commented 3 years ago

@erights https://github.com/search?q=cross-realm seems relatively widely used as a justification for use of Array.isArray, among other things.

caridy commented 3 years ago

CallableRealm?

leobalter commented 3 years ago

@caridy please no! Because the constructor throws a TypeError if new target is undefined makes me not want to call it CallableRealm.

bathos commented 3 years ago

Since it doesn't provide an actual global object/globalThis, or a container of intrinsics/builtins/etc, then the name shouldn't imply that.

Agreed, please don't call it "intrinsics" given some of us are still hopeful that a future proposal will provide what we were hoping this one would (fresh intrinsics).

victornpb commented 3 years ago

Here’s some alternative names, in no particular order:

I particularly like Realm but something like Land seems pretty close to the original but being different at the same time.

mhofman commented 3 years ago

I actually like Bubble. It's a sphere with a boundary isolating the inside and outside. And lexically it fits nicely between Agent and Compartment.

erights commented 3 years ago

Yay Bubble !

Btw, the thing the spec calls "Agent" I hope we never expose in an API with the name "Agent". This would be the worst terminology choice of all. So I discount the lexical argument for Bubble ;) . I like it anyway.

erights commented 3 years ago

Here’s some alternative names, in no particular order:

  • new Container()

Too similar to Compartment. With both in the language, will people naturally remember which is which? Is it more natural that multiple containers fit in a compartment or that multiple compartments fit into a container?

  • new Bubble()

Memorably different and enjoyably playful. But does it make any metaphorical sense to have multiple compartments inside each bubble?

  • new Land()

I just don't like it. Since I don't know why I don't, I cannot know I would not get used to it. But I don't like it.

  • new Arena()

Interesting. Would like to hear more.

  • new Canister()

Same reaction as with Container. People won't remember which is the canister and which the compartment unless there's a least a good metaphor to explain which goes into which.

  • new Crate()

Fatal Rust conflict

  • new Jar()

Fatal Java conflict

  • new Bowl()

Interesting. Would like to hear more.

  • new Capsule()

Interesting. Would like to hear more.

  • new Vase()

Interesting. Would like to hear more.

chris-kruining commented 3 years ago

just my two cents and it probably is in line with the same pushback as words like container. But here's mine: Box I see this as one of those sorting/storage boxes. the one with where you open a lid and have multiple compartments.

So in that sense I can see the logic of a word like Box when placed in context. but remove the context and it is far from descriptive enough.

Personally I also loooove the Bubble proposal. And I kind of have to say that keeping it as Realm seems fine to me as well.

chris-kruining commented 3 years ago
  • new Bubble()

Memorably different and enjoyably playful. But does it make any metaphorical sense to have multiple compartments inside each bubble?

Does it have to make sense though? I don't have a concrete example, but my gut tells me that ecma has plenty of structures that break metaphores. And as long as it is intuitive enough that a word like bubble is a no-pass-boundary that contains compartments, it seems good enough to me personally.

chris-kruining commented 3 years ago

oooh this whole bubble and metaphore thing made me think of another term, a bad one to use, but a good metaphore: Cell

A cell is a bubble (cell membrane) that has mechanisms to have very controlled "IO" and contains compartments (organelles)

so I guess Cell & Organelle fits the metaphore well, but I do not think it will be intuitive to use.

bathos commented 3 years ago

Bubble seems pretty sweet:

littledan commented 3 years ago

I like Bubble a lot! CallableBoundary doesn't make sense to me, since these are places to execute code, not just a boudary. OTOH, a bubble clearly has stuff inside it, so it makes more intuitive sense. Somehow, a Bubble feels bigger (and therefore more appropriate) to me than a Box or Cell (which somehow feel like they would just contain one little thing, whereas a Bubble could encapsulate a bunch of stuff).

Let's aim to have this bikeshed settled by next TC39 meeting.

littledan commented 3 years ago

new Bubble()

Memorably different and enjoyably playful. But does it make any metaphorical sense to have multiple compartments inside each bubble?

I'm not sure if it makes much sense to have multiple compartments inside of any of the things. I'm also not sure that compartment is the right word to use for "a context where a particular module loader is used". TBH "Compartment" wouldn't be a bad name for this proposal, with the current compartment proposal then taking a different name (loader?).

Thinking more about the relationship with compartments, a naming scheme comes to mind:

In general, "arena" could mean "a place which has its own stuff of a particular type". Or, we could call these ObjectContainer/ModuleContainer, or even ObjectBubble/ModuleBubble.

chris-kruining commented 3 years ago

I'm not sure if it makes much sense to have multiple compartments inside of any of the things. I'm also not sure that compartment is the right word to use for "a context where a particular module loader is used". TBH "Compartment" wouldn't be a bad name for this proposal, with the current compartment proposal then taking a different name (loader?).

wouldn't this be a namespace? like, in "proper" OO languages this is pretty much what they do, compartmentalization.

victornpb commented 3 years ago

wouldn't this be a namespace? like, in "proper" OO languages this is pretty much what they do, compartmentalization.

I don’t know if the semantic holds down to the details compared to other languages. But I feel like realms is its own thing, so I rather have it have its own name than break expectations.

I'm only familiar with languages that have build time namespacing. This is more like a different "runtime namespace"

littledan commented 3 years ago

I feel like "namespace" already has a different meaning in the JS context, which is things like Math or Intl. TypeScript and WebIDL already use namespace as a keyword for this purpose.

leobalter commented 3 years ago

I don't mind Bubble, it's ok. My only pet peeve for it is the metaphoric relation to the acrylic glove box, in which I'd use to explain how we manipulate things inside and we would eventually use the gloves for some a related metaphor of a membrane system. I don't have a better name, thou.

Again on the pet peeve, Bubble seems like something sealed to the point code injection feels weird. This is a very abstract thinking, thou.

From the other names without immediate objections from @erights, I don't like Arena, Capsule, or Vase. The first gives a different idea of what I have for this API and the others feel like it should be much more sealed if compared to Realms.

From my List:

0.Realm still works fine as a name for me. No implied metaphors but usage of common ES jargon.

  1. Bubble seems like a good option as a single word, with a bit of pet peeves.
  2. CallableBoundary, I don't love this name but still works as my personal favorite fallback if the names above cannot move forward.
dgeb commented 3 years ago

Atmosphere plays off the "global" metaphor and has many of the same associations as Bubble that work well. But perhaps it's a bit too on the nose.

To be a bit briefer, how about simply Sphere? I feel this works well in many senses, such as a "sphere of interest" or "sphere of control".

jmshal commented 3 years ago

World?

Jack-Works commented 3 years ago

just my two cents and it probably is in line with the same pushback as words like container. But here's mine: Box

Box is conflicting with the Record&Tuple proposal

rwaldron commented 3 years ago

Sandbox

legendecas commented 3 years ago

Sandbox

Sandbox suggests it can be used to run untrusted third-party codes. But to my understanding it's not.

Jack-Works commented 3 years ago

Sandbox

Sandbox suggests it can be used to run untrusted third-party codes. But to my understanding it's not.

Yes, a evil code can do while(1) to block the whole thread

rwaldron commented 3 years ago

Sandbox

Sandbox suggests it can be used to run untrusted third-party codes. But to my understanding it's not.

Please explain this reply

littledan commented 3 years ago

Something really nice about Bubble is that, unlike Sandbox, it implies a weaker boundary (e.g., it's not Spectre-proof).

erights commented 3 years ago

Sandbox

Sandbox suggests it can be used to run untrusted third-party codes. But to my understanding it's not.

Yes, a evil code can do while(1) to block the whole thread

That's an attack on availability, for which Realms and Compartments indeed provide zero protection, for that reason. However, Realms and Compartments provide strong protection of integrity. Compartments even provide an interesting form of protection of confidentiality.

See https://agoric.com/blog/all/taxonomy-of-security-issues/ and https://ses-demo.agoric.app/demos/challenge/

So Realms and Compartments can and should be used to run untrusted third party code, or not, depending on what threats you're trying to protect against.

erights commented 3 years ago

Something really nice about Bubble is that, unlike Sandbox, it implies a weaker boundary (e.g., it's not Spectre-proof).

Note that Compartments do provide an interesting form of protection of confidentiality, including against Spectre.

See https://agoric.com/blog/all/taxonomy-of-security-issues/ and https://ses-demo.agoric.app/demos/challenge/