Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

[Yusuke Suzuki]

Thanks for your reply.

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.


Agreed.

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.


Current Map constructor allows `class DerivedMap extends Map { }` and it is
very nice for ECMAScripters.
So I have an another question. Do you have a plan to change prototype of
ArrayBuffer and other objects to new style prototype, constructor of them
to new style like a Map constructor, and Class check(such as [[Class]] is
"DataView") to internal property check(such as
object.[[HasProperty]]("DataView")) ?
Probably because at least ArrayBuffer has no internal specialized method, I
think transforming to subclassable constructor is easy.

Regards,
Yusuke Suzuki

On Sun, Sep 30, 2012 at 6:55 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> 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
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120930/8e651226/attachment-0001.html>