As I noted in another thread, the binary data material is very preliminary and and you shouldn't read too much significance into things like this relating to that material.
However, there is a bigger issue here. You could have asked a similar question about Map.prototype. Why isn't Map.prototype a Map instances? Is this a bug or an intentional design decision? Historically, the prototype objects associated with the 9 named built-in constructors were all defined to be instances of those constructors. For example, Boolean.prototype is a Boolean instance whose value is false. In writing the specification for Map, I intentionally deviated from that pattern. I did not specify that Map.prototype is a Map instance. While it has the methods that are applicable to Map instances it does not the internal state that is necessary for those methods to actually work. For example, if you try to store a value into Map.prototype by calling its set method, you will get a TypeErrior according to the specification. May.prototype can not be used as a map object. Why did I do this? Because, we are defining a significant number new built-in "classes" and it is going to be increasingly hard to define meaningful instance state for all such prototypes. It is also arguably undesirable for most of these prototypes. Does any really think it is a good idea for Map.prototype to be globally available storage bin into which anybody can store and retrieve key/value pairs? Finally, note that the prototype objects created by ES6 class declarations typically are not valid instances of the class. Programmers would have to go out of their way to initialize them with per instance state and there is really no good reason why somebody would do that. I think it is time to recognize that the built-in ES constructors have always presented a class-like structure where it really is unnecessary and even arguably undesirable for their associated prototype objects to also act as instance objects. It's time to abandon that precedent and starting with the new ES6 built-ins to specify prototypes simply as objects that are containers of the methods shared by instances. In general, they should not be usable as instance objects. Allen On Sep 29, 2012, at 2:04 PM, Yusuke Suzuki wrote: > I've pass through ES6 rev10 draft and found that DataView.prototype object > [[Class]] isn't "DataView". > Why is it? I think allowing DataView(null, 0, 0) and using it as > DataView.prototype is better. > > -- > Regards, > Yusuke Suzuki > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
