Re: Determining what prototype should be used for an object

On 11/17/14, 12:18 PM, Anne van Kesteren wrote:
> 1) We probably want [LegacyNewObject] and [NewObject] to distinguish
> those two cases.

Hmm... OK.

> 2) We want IDL to introduce the concept of internal slots. I haven't
> really come up with a scenario yet where basing this on existing
> attribute definitions is not sufficient.

There may be various cases, sadly.  :(

For example innerHTML probably shouldn't have an internal slot.  On the 
other hand, HTMLContentElement.getDistributedNodes maybe should (hard to 
tell from the spec whether this is returning a new thing each time or 
not).  And what about other legacy stuff like Window.getSelection?

> 3) We want IDL to have attribute defaulting, to define what their
> associated internal slots have as initial value (pure convenience).

Yes.

> 4) We want IDL to define creation of objects and allocation of slots
> in more detail. In particular around Realms.
>
> Anything else? Shall I file dedicated bugs?

I don't think any of the above per se covers getElementsByTagName or 
other cases in which methods return the same object over and over; 
internal slots don't cut it there past maybe storing some sort of map in 
the internal slot.

>> For non-[NewObject] things, as discussed up-thread, the ES behavior is not
>> all that desirable.
>
> So what is an example that would still be different between IDL and
> JS?

It's more a matter of IDL having patterns (lazy creation + caching of 
objects) that JS doesn't have.  Except now JS has them, with the 
Object.getNotifier stuff.  So I'd be curious to see what JS plans to do 
with that.

Maybe we can get away with modeling all such instances as "the object 
conceptually exists at all times".  It's a bit weird as a spec device, 
since, for example, it conceptually requires hanging a countably 
infinite set of preexisting HTMLCollections off Document for purposes of 
getElementsByTagName.

-Boris

Received on Monday, 17 November 2014 17:42:10 UTC