W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2016

[Bug 27301] Define context variables, such as "context object"

From: <bugzilla@jessica.w3.org>
Date: Tue, 01 Nov 2016 14:29:59 +0000
To: public-script-coord@w3.org
Message-ID: <bug-27301-3890-xaDc5Sy81P@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27301

Domenic Denicola <d@domenic.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d@domenic.me

--- Comment #5 from Domenic Denicola <d@domenic.me> ---
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:

- https://heycam.github.io/webidl/#idl-operations should get updated to talk
about how the description of the operation may use the ambient value **this**.
- https://heycam.github.io/webidl/#dfn-create-operation-function 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**."
- https://heycam.github.io/webidl/#idl-attributes 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.
- https://heycam.github.io/webidl/#dfn-attribute-getter and
https://heycam.github.io/webidl/#dfn-attribute-setter 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 1 November 2016 14:30:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 November 2016 14:30:10 UTC