Re: Determining what prototype should be used for an object

On Mon, Nov 17, 2014 at 6:41 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

Better idea? If we need to distinguish them somehow and we don't want
to perpetuate the createElement() behavior...


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

Thanks!


> 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?

Okay, so we want [NoSlot] and explicit slot syntax:

  [[selection]] = Selection;

(Alternatively we could have an attribute declaration with [SlotOnly],
but that seems rather ugly.)


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

getElementsByTagName() is tricky since it may throw away its cache as
well (making GC observable). It being based on an internal slot that
is a map of sorts makes sense to me. Defining such a cache is up to
the API specification. What we need a hook for is making sure that
when there's nothing in the map it creates an object with the correct
Realm.


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

I'm not sure that's sensible since for getElementsByTagName() that
would not match a JavaScript-based implementation either.


-- 
https://annevankesteren.nl/

Received on Monday, 17 November 2014 18:33:22 UTC