brendan at mozilla.com
Fri Mar 13 15:29:58 PDT 2009
On Mar 13, 2009, at 3:04 PM, Mark S. Miller wrote:
> I don't understand what is being proposed. In ES3.1 terms, what would
> Object.getConstructor do? [[Class]].[[Constructor]].name makes no
> sense, since the value of [[Class]] is a string.
Yes, that sketch was based on an evolved notion of [[Class]],
hypothetical of course.
There is little point in an Object.getConstructorName that is merely a
sweeter and higher-integrity form of
Object.prototype.toString.call(obj).slice(8, -1). Tucker argued for a
way to get the true constructor object from a given instance. With the
'name' property of named functions proposal recently discussed, it's
then trivial to get the original constructor name, for both native and
Tobie showed user-defined constructor functions Parent and Child,
arranged with prototype-based inheritance as the names imply. One goal
not met by anything in ES3.1 is to get the name "Parent" or "Child",
as appropriate, given an instance or Parent or Child. Meeting that
goal requires something other than [[Class]] as spec'ed. It also needs
something less configurable and shadowable than the existing
'constructor' property of the constructor function's 'prototype' object.
Thus the idea of a [[Constructor]] internal property was skirted, but
we do not want to specify another mandatory internal property for all
objects (even if it could be optimized away as an induction variable;
the spec should avoid such redundant internal properties).
Wherefore the idea of [[Class]].[[Constructor]] based on making
[[Class]] something other than string-valued.
An obvious extension is to make [[Class]] a String instance, with an
ad-hoc non-configurable 'constructor' property, and everywhere the
spec compares [[Class]] to a string such as "Object", use ToString
or .toString (or even == -- impure! ;-) to get the right comparison
This is all just a thought experiment, and actually doing the work to
spec Object.getConstructor in ES3.1 terms, so that it satisfies the
goal of returning a reference to the native or user-defined
constructor that was invoked to construct obj, might lead to a better
In any event, this issue is separate from the 'name' property of
function instances, which Allen is deferring from ES3.1, but we're
continuing to hash out for Harmony.
So if, as appears likely, we don't do either 'name' or
'Object.getConstructor' for ES3.1, we may find a better Harmony-
targeted spec formalism and particular solutions couched in it. But I
suspect it's worth working out the minimal solution now in ES3.1 terms.
Does this help?
> On Fri, Mar 13, 2009 at 2:21 PM, Brendan Eich <brendan at mozilla.com>
>> On Mar 13, 2009, at 6:22 AM, P T Withington wrote:
>>> On 2009-03-13, at 01:04EDT, Brendan Eich wrote:
>>>> To your point, which I addressed in different terms: we could make
>>>> Object.prototype.toString look for [[Class]].[[Constructor]].name
>>>> [[Constructor]] is unnameable-by-script and references the class's
>>>> constructor function. This would satisfy Tobie's wish while
>>>> avoiding the
>>>> mutation hazards inherent in using constructor.name. Either
>>>> solution wants
>>>> the function name property to be standard.
>>> Can we go one step further? I want (something like)
>>> Object.getOwnConstructor() to return Object.[[Class]].
>>> [[Constructor]]. I
>>> want to be able to get a handle on the constructor of the object,
>>> not just
>>> the name of that constructor (since in some cases that name might be
>>> 'anonymous' which doesn't help me). Is that a possibility?
>> For Harmony, sure. It would be Object.getConstructor, I think,
>> since there
>> is no connotation of "get property from this object or an object on
>> prototype chain", but Allen may have a different thought.
>> For ES3.1 the time to propose this was last year when the spec was
>> in flux,
>> freely available for review, and not being frozen for implementation.
>> Sure, we could "sneak" Object.getConstructor in, but that is a good
>> way to
>> be late and bloated if done for N such "easy additions", N growing
>> large as we go. Maybe we can agree to hold the line "just this
>> once". I'm
>> skeptical; a precedent often takes on a life of its own.
>> Es-discuss mailing list
>> Es-discuss at mozilla.org
More information about the Es-discuss