[Fwd: Setting inheritance chains, <|, extends, class and all the stuff]

Somehow, this did not get into the list, so I am resending it... 
hopefully it won't get duplicated.

-------- Original Message --------
From: Herby Vojčík <herby at mailbox.sk>
Subject: Setting inheritance chains, <|, extends, class and all the stuff
Date: Wed, 21 Mar 2012 18:58:59 +0100
To: ECMAScript discussion <es-discuss at mozilla.org>

Hi,

as for setting the [[Prototype]] chains with constructor function, I see
there are three scenarios:

  CP: aka 'classical inheritance'
    SubCtr.[[Prototype]] is set to SuperObj
    SubCtr.prototype.[[Prototype]] is set to SuperObj.prototype

  C: aka 'constructor inheritance'
    SubCtr.[[Prototype]] is set to SuperObj
    SubCtr.prototype.[[Prototype]] is set to Object.prototype

  P: aka 'prototype inheritance'
    SubCtr.[[Prototype]] is set to Function.prototype
    SubCtr.prototype.[[Prototype]] is set to SuperObj

I propose these should be covered syntactically this way:

  CP:
    class SubCtr extends SuperObj { ... }
    // and if possible also, to have more basic construct without
    // defining methods, just the constructor function:
    function SubCtr (...) extends SuperObj { ... }

  C:
    SuperObj <| function SubCtr (...) { ... }

  P:
    SuperObj <| class SubCtr { ... }

Precondition:
   class's extends keyword is agreed to create CP type inheritance

Rationale:
   If extends represent the classish CP inheritance, and looking at all
other uses of <| you see that its spirit is to set only the
[[Prototype]] of thing described by RHS, we can use both and have them
unambiguously define what kind of [[Prototype]] they set only based on
which construct is used, not based on structure of LHS.

   This plays with "explicit is better then implicit" card - you know
instantly when you read/write code, what type of chaining you want to
accomplish, so readability and hidden bugs from using variable LHS could
be prevented.

Comments?

Herby