On 6/13/14, 1:51 PM, Allen Wirfs-Brock wrote:
Unless, I misunderstand I don't think Jason is proposing eliminating @@create.
I had assumed he was... I'm not sure I see the point if we're not doing
that.
The object you return is an instance of the superclass and not of the subclass.
Ah, right.
So just to make sure, now that I think about it: in the @@create setup,
where is the prototype of the object set? What is the prototype of the
thing @@create returns?
Or put another way, is there really a difference, conceptually, between
doing the "create an instance of the superclass and then change the
prototype" thing and what @@create gives us?
The key thing that @@create is doing is separating determining the physical
characteristics of an object (making it exotic, branding it, using a custom C
struct as its representation, etc.) from logically initializing it at an
appropriate place within some class hierarchy
Looking at what's involved in object allocation in at least
SpiderMonkey, the following pieces of data are required to be known at
object creation time:
1) The Realm to use.
2) Some metainformation about the exotic-or-not nature of the object,
its internal layout, etc.
These are effectively not mutable in SpiderMonkey.
In addition to those, it's good to have the prototype available at
object-creation time as well, since later dynamic prototype mutation,
while possible, leads to deoptimization in the JIT. This may be a
SpiderMonkey-specific issue, of course.
-Boris
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
