Finding a "safety syntax" for classes

Nadav Shesek nadav at
Sat Mar 24 15:01:22 PDT 2012

What about setting arbitrary expressions as the value for prototype
methods? Being able to use higher-order functions to dynamically create
functions is very important for functional style programming. I use it very
often to decorate functions, compose functions together, set partially
applied functions as methods, etc. It seems to be impossible with syntax
proposed here - I think adding it to the "safety syntax" is very much
needed and should not be over looked.

On Sat, Mar 24, 2012 at 4:28 PM, David Herman <dherman at> wrote:

> On Mar 21, 2012, at 9:13 AM, Allen Wirfs-Brock wrote:
> On Mar 20, 2012, at 11:32 PM, David Herman wrote:
> Well, hang on now. The 'constructor' syntax is not "just the constructor
> property." It still carries special status; the semantics of a class says
> "look for the property called 'constructor' and make that the [[Call]] and
> [[Construct]] behavior of the class."
> Actually, the semantics is probably more like:  the value bound to the
> <classMame>  is the function object defined by the <methodDefinition> whose
> <propertyName> is "constructor".
> Yes, sure. Doesn't change the point: 'constructor' is still a special,
> distinguished method.
> Regardless of whether we spell it 'constructor' or 'new' it requires
> special semantics that says "there's one distinguished method form in the
> body that determines the constructor of the class."
> There is one distinguished method that *is* the class object (aka, the
> constructor function).  A class declaration essentially desugars into the
> definition of a constructor function and a object that is the prototype
> associated with that constructor.
> Again, doesn't change the point: whether you spell it 'new' or
> 'constructor' it's still a distinguished method, and then you can desugar
> that however you want.
> The question is how we spell that. This is 99.9% a surface syntax
> question. Tou could argue that spelling it 'new' should define a ["new"]
> method, or a ["new"] method and a ["constructor"] method, or just a
> ["constructor"] method. If the latter, it's semantically *identical* to
> spelling it 'constructor'. But even if we chose one of the other two
> alternatives, the semantic differences here are minor, and the ergonomics
> of the syntax matter.
> You need to drop the [ ]'s  (although I'm not sure what you meant by
> them...
> I meant that there is a property of the prototype that you can access via
> either p["new"] or p["constructor"] or both, depending on which semantics
> we decide to give. No matter what the surface syntax, any of those
> semantics is available to us. I say:
>     a) spell it "new" -- ergonomics trumps corner cases; hard cases make
> bad law
>     b) desugar it to the constructor function and the p.constructor
> property only
>     c) i.e., don't create a property -- no more prototype pollution
> please
>     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.
> Personally I think the answer should be "A" which implies that we have
> class-side inheritance.   This is a departure from current practice but
> because "classes are functions" there is no way in ES<=5.1  to set up class
> side inheritance other than by mutating __proto__.
> I always found this the more appealing, but then again, if I'm supposed to
> be going with the opposite of my instincts (see above), then maybe I should
> disagree with you. ;)
> I would guess that your instinctive response comes from thinking about a
> "class" is something more than just  a composite of objects.  We can talk
> more about this later after I respond to Mark
> I think you misread me. My instinctive response agrees with yours, not
> Mark's.
> If the value of SOMEEXPRESSION is a constructor function (typeof ==
> "function" && and has a "prototype" property) then the new constructor
> inherits from SOMEEXPRESSION and the new prototype inherits from
> SOMEEXPRESSION.prototype.  Otherwise, the new consructor inherits from
> Function.prototype and the new prototype inherits from SOMEEXPRESSION.
>  That is essentially the semantics I've defined for
>        SOMEEXPRESSION <| function () {}
> I'm not happy with that semantics, for either classes or <| (I believe
> others have objected on the list to the special-case semantics for <| as
> well). Since functions are objects, you can pass functions into contexts
> that expect an object and those contexts don't need to care whether the
> object they have is a function or an object. So this will lead to WTFjs
> moments where people take an object they got passed in from someone else
> and create a class with it, and it won't be wired up right because they
> didn't realize the object was a function.
> This kind of special-case ad hoc type testing in the semantics has a bad
> smell. It reminds me of stuff like the Array constructor that special-cases
> the number argument.
> B = do{
>       let B = SOMEEXPRESSION <| function B(...) { ...};
>       B.prototype= SOMEEXPRESSION.prototype <| {constructor: B, ...}
>       B
> }
> (or to be maximally explicit}
> B= do {
>     let B = function B(...) {...};
>     if (typeof SOMEEXPRESSION == "function" && typeof
> SOMEEXPRESSION.prototype == "object") B.__proto__=SOMEEXPRESSION;
>     B.prototype= SOMEEXPRESSION.prototype <| {constructor: B, ...}
>     B
> }
> Nit: you'd need to bind the result of SOMEEXPRESSION to a temporary, to
> avoid duplicating side effects. </macrology nerd>
> Dave
> _______________________________________________
> es-discuss mailing list
> es-discuss at

<me><name>Nadav Ivgi</name><profession>Software
Developer</profession><phone>+972-50-3650394</phone><blog></blog><timezone>GMT +2</timezone></me>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list