Russell Leggett wrote:
Finally, regarding:
>>
>>>
>>> d) an explicit 'constructor' method overrides the implicit
creation of the 'constructor' method but does not define the
constructor function
>>>
>>> Why d)? Remember, the .constructor idiom is a *very weak*
idiom that many JS programs don't follow. If a JS program has some
reason to use 'constructor' for a different purpose, trust them.
>>
>> I believe the constructor idiom is most commonly not followed
today when the prototype property of a function is set to a new
object (perhaps defined using an object literal) and correctly
dynamically setting the "constructor" property is an extra step
that is easily forgotten (an usually as no ill-effects)
I really don't like d) very much at all. I think one of the
advantages that use of class declaration can offer is a higher
integrity implementation of the latent ES class model. In
particular, it could more strongly enforce the <ctor>.prototype
=== <ctor>.prototype.constructor
[Allen: extra .prototype on the left of ===, right?]
invariant. I don't think a class declaration should be allowed to
set the prototype's constructor property to anything other than
the actual class object (ie constructor function). It also should
make <ctor>.prototype writable:false and configurable: false, just
like is done for all of the chapter 15 constructors. In addition,
I suggest that we should go one step further and also make
<ctor>.prototype.constructor writable:false and configurable:
false. It isn't clear to me why ES1 chapter 15 made all
<ctor>.prototype ReadOnly/DontDelete but didn't do the same for
chapter 15 <ctor>.prototype.constructor properties.)
ES1 did that because implementation(s) possibly not including my "Mocha"
in Netscape 2 but probably including IE3-4 JScript did that, because (if
I can recall correctly) the built-ins constructors' .prototype property
was used to find "the original value of Object.prototype" or "the
original value of Array.prototype" given an internal memo that strongly
referenced Object or Array, e.g. Without this, you'd need two internal
memos, one for the ctor and one for its original .prototype value.
Kind of a dopey reason, but there it is.
+1
This is actually one of the reasons I still come down on constructor
over new - I'd really like to discourage screwing around with
<ctor>.prototype.constructor. That always felt like a major wart IMO.
Making it ReadOnly/DontDelete would be icing on the cake. Not sure if
we can squeeze it into max/min, but I like it. Classes are a leaky
abstraction, as you said, but I think the major gain is making it easy
to do things the right way, even if we don't really add much
functionality.
The issue is "what is the right way?" I agree that classes shouldn't be
too little veneer on oonstructor functions, though. Locking down the
class constructor's .prototype is ok with me. It helps us move toward
self-hosting the built-ins.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
