Re: Non-constructible constructors and Arrays

On Thu, Jul 28, 2011 at 7:12 PM, Allen Wirfs-Brock
<> wrote:
> On Jul 28, 2011, at 5:04 PM, Jonas Sicking wrote:
>> As I asked above, what would the mutating functions do to "live"
>> NodeList? And IMHO only APIs that want to return "live" objects should
>> return NodeLists. Others should simply return arrays.
> In ES5 all of the Array.prototype functions are defined to operate upon generic objects with "array indexed" (ie, integer string values) properties. The objects they operate upon do not need to be Array instances. The functions are specified in terms of the basic ES5 internal operations such as [[Get]], [[Put]],  etc.  Such generic objects (or even Array instances for that matter) may, in ES5, have non-writable and non-deletable properties and the objects may be non-extensible.  For that reason, the array algorithms all explicitly define how to deal with such situations.  Generally, they throw when they try to modify a property in a manner that is forbidden for that object.
> If a DOM implementation provides reasonable implementations of [[Get]], [[Put]] and friends then the Array functions should just work on its DOM objects. Trying to reverse a read-only DOM object may not do anything useful, but its unuseful behavior would still be fully specified.

I'm very aware how the Array functions are defined. The problem is
that there aren't any reasonable defaults we could provide for
NodeList's [[Put]] operations simply due to what a NodeList

The only reasonable thing we could do is to make all mutating
operations throw, which frankly would be a pretty strange API. I.e.
all NodeLists would have whole host of operations like .push and
.shift which always would throw. It would seem much better if those
operations weren't there.

This discussion has come up a number of times and the conclusion is
always the same. Several solutions have been proposed, some more
workable than others, but unfortunately this thread doesn't mention
any of them, nor does it bring up any new information which would help
us get any closer to a conclusion.

/ Jonas

Received on Friday, 29 July 2011 02:27:00 UTC