Re: DOM collections index out of bounds and JavaScript.

Garrett Smith:
> Objects references are passed as value in ES but that doesn't mean the
> same thing you're intending here. Here, by "pass by value", you mean
> to convey that a copy of value of the object is passed.

Yes, sorry for the imprecise language.  Obviously ES only has pass by
value.

> A method that accepts an array can use that array without storing a
> reference to it. And if it needs those items, then it can make a
> "defensive copy" of the Array.

Yeah, sequences are meant to be like that: methods would be required to
take a “defensive copy” of the array, and not keep a reference to the
object that was passed in.

> …
> The difference here is that the object that was passed in uses normal
> ES syntax; it's pass by value (value of reference) not referenced by
> the object. The effect is what you wanted, I think, and that is that
> 1) the method that accepts the array makes a defensive copy of it and
> 2) that the method (or getter) that returns the array always returns a
> new copy of it.

Yes, that’s the intent.

> But where is the array host object used?

That’s for arrays – type T[] – not sequences.

> That seems like the main issue to me. What are a Collection object's
> indexed properties? Are they real object properties or is there a
> proxy for [[Get]] and [[Has]]? Both behaviors can be seen in
> implementations but it varies, depending on the implementation and on
> the object.

As currently defined, they are real properties.

> But where are proxies really needed? How important is it, for example,
> for document.styleSheets[-1] to throw an "index out of bounds"
> exception, or for document.childNodes(99999) to return null instead of
> undefined?

I think document.styleSheets[-1] returning null or throwing an exception
is inconsistent with, say, regular ECMAScript arrays, so IMO that’s not
something we should encourage.

> It seems that some implementations have gone out of the way to use
> proxies to adhere to the spec to fulfill the odd cases above (albeit
> inconsistently) while others have chosen to just use property access
> to return undefined.

I’m not sure that implementations are slavishly following the Web IDL
spec just yet.

> How important are those cases? Do we have any bug reports for
> implementations returning `undefined` instead of throwing/returning
> null?

I don’t know of bug reports.

> I get that the spec requires ob[n] to delegate to item, and so for
> that a proxy is needed. But what type of situation is it really
> necessary for obj[n] to delegate to item? Which Collections really
> need a proxy to function as required by code?

I’m not sure that proxies are required to make ob[n] delegate to item,
as long as n is always the name of a property that exists on the object.
That’s how the spec defines it at the moment: whenever there’s a
“supported named property” (i.e., a value for n that is in range, as it
were) then an accessor property must be defined on the object, where the
getter calls item.

It’s the “define a property on the object at the right time” bit that
could be tricky, though.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Sunday, 31 October 2010 21:23:49 UTC