This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27301 - Define context variables, such as "context object"
Summary: Define context variables, such as "context object"
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2014-11-11 11:47 UTC by Anne
Modified: 2016-11-01 14:42 UTC (History)
6 users (show)

See Also:


Description Anne 2014-11-11 11:47:07 UTC
The current flow is:

  JavaScript -> IDL -> API spec -> IDL -> JavaScript

I think it would be useful if IDL defined a bit more explicitly what the API spec has access to. E.g. one thing we often stumble with is something DOM calls the "context object". Perhaps IDL could "invent" something named "this" and hand that to the API spec.

Another thing we might need access to is the Realm. It has been suggested to base origin checks on that. (Although in that case IDL would also need to make it clear what the origin is of a Realm, as JavaScript doesn't do that.)
Comment 1 Anne 2015-06-18 05:18:22 UTC
What I also want is a defined variable name for the value passed to setters that I can refer back to. I usually use something like "the given value" but that's not really exact. It needs to be something that IDL passes in.
Comment 2 Anne 2015-07-13 07:06:49 UTC
I thought about this a bit and how it would be best to define this. I think it would make the most sense if IDL derived the algorithm it has to invoke from the interface/class and then invokes it with a set of parameters.

So e.g.

  interface SomeClass {
    boolean someMethod();

ends up generating an algorithm name SomeClassSomeMethod that IDL invokes with "this" as the first argument and in this case no other arguments since someMethod() takes none. The specification that defines this interface would define the SomeClassSomeMethod algorithm.

That gets us much closer to a formal way of defining APIs. For getter/setter properties you'd obviously have two such algorithms, the latter passed a value argument along with "this". Note that for getter/setter we could also generate default algorithms, once bug 27354 is fixed, so that specifications only need to define these algorithms if something more complex happens than getting and setting an internal slot.

(And then further in the future IDL could standardize the metalanguage used in these algorithms, such as "return", "continue", loops, etc. Which will hopefully make specifications more readable than they are now.)
Comment 3 Travis Leithead [MSFT] 2015-07-17 15:02:09 UTC
I certainly see the attractiveness of this for spec writers. If more of the boilerplate can be automated, that's pretty good.

On the other hand, this might lead to the level of formalism of creating a new spec programming language with full syntax validation, which might restrict the freedom of prose in algorithms, thus making it trickier to write "correct" specs, and serving as even more of a barrier-of-entry for new spec writers.
Comment 4 Anne 2015-07-17 15:09:59 UTC
Ideally specifications aligning on style lowers the barrier to copy-and-paste patterns (which is how most new specification writers start out).
Comment 5 Domenic Denicola 2016-11-01 14:29:59 UTC
I think the style described in comment 2 is rather ambitious and is kind of a separate bug from formalizing the ambient values available.

Regarding the original request, I think we have two concrete things to solve these days (realms are in a better place due to other work):

- a "this value" of some sort, which is an IDL object (not a JS object)
- a "given value" for setters, which is an IDL object (not a JS object)


I'd propose we make the "this value" ambient and the "given value" explicit, so algorithms are written like:

The `foo()` method `Bar` objects performs these steps:

1. Let _qux_ be **this**.[[qux]].
1. Let _realm_ be the <a>relevant Realm</a> of **this**.
1. Return 5.

The `baz` attribute of `Bar` objects, on setting to _value_, performs these steps:

1. Set **this**.[[baz]] to _value_.

(Typographical note: **this** could, in HTML, end up being <b>this</b>, or maybe <code>this</code>. Semantically it should not be <emu-val>this</emu-val> since it is an IDL value instead of an ECMAScript value---even though, for objects, the distinction is fairly pointless.)


To handle this, we'll need to edit the following sections, in my estimation:

- should get updated to talk about how the description of the operation may use the ambient value **this**.
- step 2.6 should be updated from "on _O_ if _O_ is not **null**" to something like "with the ambient value **this** set to _O_, if _O_ is not **null**."
- should talk about how attributes have "on getting" and "on setting" steps, and how "on setting" steps accept a single argument which is an IDL value.
- and should be updated to refer back to that definition of "on getting"/"on setting", and in the case of the setter, explicitly pass in _idlValue_.

Also, it may help to start a new top-level section, say, "Writing Web IDL-Using Specs" or some better name. It would contain examples of these patterns, like my above "so algorithms are written like". The main purpose is to make people aware of the magic sentences you should use when introducing operation steps/attribute getters/attribute setters. Although maybe these should just be incorporated into the #idl-operations and #idl-attributes sections instead for now, and eventually when we get enough material we could pull it out into something top-level.
Comment 6 Boris Zbarsky 2016-11-01 14:42:46 UTC
> even though, for objects, the distinction is fairly pointless.

It's not entirely pointless, because given browser extension APIs the mapping from the IDL value to the ES value is more or less one-to-many....  This means that anything that wants to manipulate the ES value may need to consider saying _which_ ES value.