[Bug 27354] Internal slots

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27354

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian@hixie.ch

--- Comment #8 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
After a long conversation with Anne on IRC, I really don't think this is a good
idea.

- The [[slots]] stuff in ES6, IMHO, makes the ES6 spec very very hard to read.
We really should not encourage that style in more specs.

- We already have the equivalent readable way to do this; HTML does it all
over, for example. You just say that "A Foo object has a bar state" and then
define things in terms of a bar state. (It's indeed a mistake to do this by
reusing the names of exposed attributes; don't do that.)

- Anne suggested that this would help with defining what is going on when you
use .call() to invoke a method from one object on another object of the same
type, but I don't understand why that is hard to do today, nor why that problem
really has anything to do with globals or slots.

- Anne suggested it might help with defining associated globals, but that seems
like a non-issue to me. I don't understand the problem there at all. Why are
globals hard to define in prose? It seems like a one or two sentence definition
would cover all cases.

- Anne suggested it might help with changing prototypes during element adoption
across global objects. First, I think changing prototypes at all here is a
mistake (most browsers don't do it), and second, even if we do want to do this,
it's just a bit of prose in the DOM spec.

- Anne suggested it might help with creation of objects, but I don't understand
how.

- Anne said something about Object.observe(), but didn't elaborate. I'm
guessing the idea is to be able to watch attributes. However, we want to be
REALLY CAREFUL about which attributes we expose to Object.observe(), because
every property we expose forces the implementation to not have lazy evaluation
for that attribute. IMHO we should not make this trivial to spec. If there's a
property we really want to expose, we should make that clear somehow, e.g. with
an [Observable] annotation, and we should define in prose when the value
changes.

None of this requires any changes to IDL.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 20 November 2014 18:39:41 UTC