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
user-defined functions.
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
result.
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
solution.
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?
/be
On Fri, Mar 13, 2009 at 2:21 PM, Brendan Eich <[email protected]>
wrote:
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
where
[[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
its
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
quite
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.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
