On Mar 12, 2009, at 8:28 PM, P T Withington wrote:
On 2009-03-12, at 21:38EDT, Brendan Eich wrote:
That's the rationale in a nutshell for the de minimus ES1 (pre-ES1,
I had it in Netscape 3 if not 2) setting of f.prototype.constructor
to f when creating f.prototype on demand.
It could be argued it's too implemnetation-oriented but we had a
hard time figuring out how to elaborate it without imposing a per-
instance cost (as Tucker chose to do, but that was his choice) on
all objects. I remember talking through this in ES1 days, early
1997 probably.
Ideally, I could have what I want with a per-constructor cost,
rather than a per-instance cost. Since we know each instance
already has a [[Class]] and a [[Prototype]] property and we don't
want to add another slot of overhead, we could expand one of those.
As an aside, you might think we could (ignoring tricks to make
[[Class]] implicit by allocating all objects of the same class from a
given page or larger aligned chunk of memory) eliminate [[Class]] and
have only [[Prototype]], with internal methods such as [[Get]] and
[[ThrowingPut]] defined so as to be unnameable by script on the
prototype object.
This would have nice properties for composing, e.g., custom extensions
to native instances, e.g., Date instances. Date methods such as
Date.prototype.toString would find the internal state, named
[[Private]], say, by looking up an unnameable-by-script identifier
starting from the FancyDate instance, then looking in its true Date
prototype:
js> function FancyDate() {}
js> FancyDate.prototype = new Date(0)
Wed Dec 31 1969 16:00:00 GMT-0800 (PST)
Alas it doesn't work:
js> fd = new FancyDate
Date.prototype.toString called on incompatible Object
From ES3 15.9.5:
''In following descriptions of functions that are properties of the
Date prototype object, the phrase “this Date object” refers to the
object that is the this value for the invocation of the function. None
of these functions are generic; a TypeError exception is thrown if the
this value is not an object for which the value of the internal
[[Class]] property is "Date".''
Behold nominal typing in the built-ins, separate from prototype-based
delegation. I regret this impurity, but it's deep and it reflects
implementation biases of the time, still present today.
The [[Prototype]] property is already per-constructor, but it's an
Object itself, and its semantics mean I can't do what I want there.
Along your line of thought that the [[Class]] value is not really a
string (because you can only get to the specified string with the
toString 'accessor') why can't the [[Class]] value be per-
constructor, and have a slot that takes you back to the constructor,
via some suitably-named accessor? (Too bad `constructor` is already
used.)
Perhaps this all becomes moot when I have real classes in es4, but
until that time...
ES4 is no more, its sound parts survive in Harmony. The "classes as
sugar" idea lives in Harmony too, and such classes should be able to
model or even implement the built-in nominal types, I think.
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.
/be
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
