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

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27301

--- Comment #1 from Anne annevk@annevk.nl ---

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.

Contact us to advertise here
# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27301

--- Comment #2 from Anne annevk@annevk.nl ---

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.)

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27301

Travis Leithead [MSFT] travil@microsoft.com changed:

       What    |Removed                     |Added

             CC|                            |travil@microsoft.com

--- Comment #3 from Travis Leithead [MSFT] travil@microsoft.com ---

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.

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27301

--- Comment #4 from Anne annevk@annevk.nl ---

Ideally specifications aligning on style lowers the barrier to copy-and-paste patterns (which is how most new specification writers start out).

# bugzilla at jessica.w3.org (7 months ago)

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]].
  2. Let realm be the <a>relevant Realm</a> of this.

  3. 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:

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.

# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27301

Boris Zbarsky bzbarsky@mit.edu changed:

       What    |Removed                     |Added

             CC|                            |bzbarsky@mit.edu

--- Comment #6 from Boris Zbarsky bzbarsky@mit.edu ---

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.

Want more features?

Request early access to our private beta of readable email premium.