<html><body><div style="color:#000; background-color:#fff; font-family:verdana, helvetica, sans-serif;font-size:12pt"><div id="yiv0346624966"><div><div style="color:#000;background-color:#fff;font-family:verdana, helvetica, sans-serif;font-size:12pt;">Eric -<br><br><br>On class-based inheritance<br><br>Gang of Four says prefer composition to inheritance, not avoid inheritance altogether.<br><br>As
 you suggest near the end of your last reply, you can use composition or
 injection with any of those constructors in the inheritance hierarchy 
to add or override behavior. It does not follow that we should never use
an inheritance hierarchy for generally shared or default behavior.<br><br>If
 the argument is against the class extends super syntax in ES6, I agree 
it's not necessary in ES.  But as others have pointed out, it's an opt-in 
feature that we won't be forced to use (big thank you to everyone for 
supporting backward compatibility).  As David Bruant noted, some prefer not to use Object.create() and just use new function() instead (I'm one of them - I'm guilty).<br><br>If the argument is against 
them in all cases, we still have to use care with mixins (see 
ActiveRecord for an extreme case) and interfaces, etc., as even a change
 to a trait or interface can have consequences downstream.<br><br><br>Out here in Userland<br><br>I've 
seen the same pathology you describe in several codebases - it also 
happens with CSS descendant rules and id selectors, !important rules and
 inline style attributes to override them *this one time*.  <br><br>But, I haven't seen coupling as a *problem* with inheritance per se so much as that a constructor is doing *any* work at all - by which I mean side-effects - which is an argument for using Object.create - which I now note with irony.  <br><br>The one thing that saved
 us from dread of *OMG we have to re-visit everything* has been reliance on unit tests - test-driven-development, or 
test-during-development really does reduce the fear of later confusion - but that's another discussion entirely.<br><br><br>Sorry for preaching to the choir and/or ruffling feathers<br><div id="yiv0346624966yui_3_7_2_33_1372459179140_55"><span id="yiv0346624966yui_3_7_2_33_1372459179140_217"><br></span></div><div style="color:rgb(0, 0, 0);font-size:16px;font-family:verdana, helvetica, sans-serif;background-color:transparent;font-style:normal;" id="yiv0346624966yui_3_7_2_41_1372459179140_55"><span id="yiv0346624966yui_3_7_2_41_1372459179140_134">DFKaye<br><br><br></span></div><div style="color:rgb(0, 0, 0);font-size:16px;font-family:verdana, helvetica, sans-serif;background-color:transparent;font-style:normal;" id="yiv0346624966yui_3_7_2_41_1372459179140_144"><span id="yiv0346624966yui_3_7_2_41_1372459179140_134"></span></div><div><br id="yiv0346624966yui_3_7_2_41_1372459179140_57"></div>  <div class="yiv0346624966yui_3_7_2_41_1372459179140_59"
 id="yiv0346624966yui_3_7_2_41_1372459179140_60" style="font-family:verdana, helvetica, sans-serif;font-size:12pt;"> <div class="yiv0346624966yui_3_7_2_41_1372459179140_63" style="font-family:times new roman, new york, times, serif;font-size:12pt;"> <div dir="ltr"> <hr size="1">  <font face="Arial" size="2"> <b><span style="font-weight:bold;">From:</span></b> David Bruant <bruant.d@gmail.com><br> <b><span style="font-weight:bold;">To:</span></b> Eric Elliott <eric@ericleads.com> <br><b><span style="font-weight:bold;">Cc:</span></b> es-discuss <es-discuss@mozilla.org> <br> <b><span style="font-weight:bold;">Sent:</span></b> Friday, June 28, 2013 3:55 PM<br> <b><span style="font-weight:bold;">Subject:</span></b> Re:<br> </font> </div> <div class="yiv0346624966y_msg_container"><br><div id="yiv0346624966">
  

    
  
  <div>
    <div class="yiv0346624966moz-cite-prefix">Le 29/06/2013 00:14, Eric Elliott a
      écrit :<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><span class="yiv0346624966yui_3_7_2_41_1372459179140_70" style="font-family:arial, sans-serif;font-size:12.666666984558105px;">
          "</span><span class="yiv0346624966yui_3_7_2_41_1372459179140_71" style="font-family:arial, sans-serif;font-size:12.666666984558105px;">I'm
          however very interested if you could take a look at the
          current proposal and tell if you can pin down how the current
          proposal makes classes harmful for code maintainability."<br>
          <br>
          Basically, my argument is that the whole paradigm of a class
          with a single ancestor, and any mention of that ancestor in
          the implementation of the child (referring to the parent in
          the constructor, for instance), is fundamentally flawed and
          problematic. `extends` harms code maintainability by virtue of
          creating the brittle hierarchy / gorilla-banana problem I've
          already described.<br>
          <br>
          The problem isn't how it's done in JavaScript or ES6. The
          problem is that it's done at all.<br>
          <br>
          Class gets people thinking in a fundamentally broken paradigm
          for good OO design<br>
        </span></div>
    </blockquote>
    The rest of JavaScript remains. ES6 classes are just a sugar on top
    of the ES5 runtime concepts (objects with [[Prototype]], [[Get]],
    [[Set]], etc.).<br>
    People already think in a broken way when it comes to software.
    Software is hard. Lots of people model data inside strings. I
    believe this is a much bigger problem than classes. What's the
    solution for stringly typed code?<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr"><span class="yiv0346624966yui_3_7_2_41_1372459179140_72" style="font-family:arial, sans-serif;font-size:12.666666984558105px;">I
          saw a recent example of one of the problems with
          single-ancestor inheritance in a talk. I wish I could remember
          which one.</span></div>
    </blockquote>
    I believe it was this talk by Angus Croll
    <a rel="nofollow" class="yiv0346624966moz-txt-link-freetext" target="_blank" href="https://speakerdeck.com/anguscroll/the-why-and-how-of-mixins-in-flight">https://speakerdeck.com/anguscroll/the-why-and-how-of-mixins-in-flight</a><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr"><span class="yiv0346624966yui_3_7_2_41_1372459179140_73" style="font-family:arial, sans-serif;font-size:12.666666984558105px;">The
          illustrations were great:<br>
          <br>
          Animal<br>
            - Walking</span>
        <div><span class="yiv0346624966yui_3_7_2_41_1372459179140_74" style="font-family:arial, sans-serif;font-size:12.666666984558105px;"> 
              - Monkey</span></div>
        <div><span class="yiv0346624966yui_3_7_2_41_1372459179140_75" style="font-family:arial, sans-serif;font-size:12.666666984558105px;"> 
              - Human<br>
              - Flying</span></div>
        <div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px;">    - Bird</span></font></div>
        <div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px;">    - Bee<br>
            </span></font>
          <div style=""><span class="yiv0346624966yui_3_7_2_41_1372459179140_81" style="font-family:arial, sans-serif;font-size:12.666666984558105px;"> 
              - Swimming</span></div>
          <div style=""><font face="arial, sans-serif"><span style="font-size:12.666666984558105px;">    - Fish</span></font><br>
            <font face="arial, sans-serif"><span style="font-size:12.666666984558105px;">    - Whale</span></font><br>
            <br>
            <font face="arial, sans-serif"><span style="font-size:12.666666984558105px;">Now we need
                alligator and duck.</span></font><br>
            <br>
            <font face="arial, sans-serif"><span style="font-size:12.666666984558105px;">I understand that
                JavaScript doesn't restrict you from doing things like
                mixins as well... but when you're 14 months into a
                project, and THEN you have to add the alligator,
                suddenly you're mixing paradigms in ways that diverge
                significantly from the style of the rest of the code
                base. At this point, the code is already arthritic and
                brittle. Fitting these things in at this point is a lot
                less trivial.<br>
              </span></font></div>
        </div>
      </div>
    </blockquote>
    Classes and the single-ancestor pattern are limited in the sort of
    objects they can model. Animals are such an example.<br>
    But you can model other simpler things that don't have properties
    that cross over. Classes can work for these cases.<br>
    I believe that these cases are numerous and classes can work for
    them. <br>
    <br>
    Classical inheritance is a problem when that's the only tool you
    have. But if you have a decent understanding of what you're trying
    to model, you can use classes when that fits and other more
    appropriate mechanisms when they're available. The very tool you use
    to model something can already be of help to others to understand
    the "shape" of what you're modeling. <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div style=""><font face="arial, sans-serif"><span style="font-size:12.666666984558105px;">
                If you're relying on things like super in the rest of
                the code, how does the new stuff properly invoke the
                constructors of multiple ancestors which are designed to
                be single ancestors?<br>
              </span></font></div>
        </div>
      </div>
    </blockquote>
    Does the ES6 super has the same issue than the Java one? I really
    don't feel I have enough expertise in the matter to say yet. <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div style="">I can tell you how I've seen these situations
            handled in the real world, virtually everywhere the problem
            has cropped up (pretty much everywhere that class was relied
            on heavily). Massive refactors. Code rewrites. Lots of
            wasted time.<br>
          </div>
        </div>
      </div>
    </blockquote>
    Yes, when the wrong tool is used for a job, people pay it later. It
    also happens in JavaScript. In my experience, it's often more a
    problem of not understanding your model enough when first writing
    the code. In my experience again, it's hard to plan everything in
    advance and choosing class or not class is rarely the heart of the
    problem when you've mis-modeled your software.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div style="">
            Class sugar might save developers a few keystrokes today,
            but it will come back to bite them hard later. Lots of
            people are paying for Backbone's .extend().<br>
            <br>
            If it added value, that would be one thing. But it doesn't
            actually do anything that couldn't have been done just by
            replacing it with a constructor that produced objects that
            could be passed into those constructors to produce new
            objects.</div>
        </div>
      </div>
    </blockquote>
    This sort of argument leads us nowhere. By that argument, we can
    remove maybe 70% of the JS built-ins. All the Math functions and
    constants can go, all Array.prototype algorithms... Object.create
    isn't even necessary if you have functions and 'new', etc.<br>
    Classes offer a nice sugar to cover *some* use cases, *some*
    modelisation cases. Among expert-enough people, using classes may
    become the sign of simple models (when there is no need for
    specialization) or simple specialization patterns. That's a good
    thing. It's not big, but it's a good thing.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div style="">I have seen the problems in code at Adobe, at
            Tout, and at BandPage (my last three jobs, that all used
            Backbone).<br>
          </div>
        </div>
      </div>
    </blockquote>
    I would be interested in see code samples describing your problem. I
    do believe you and I agree with you by intuition, but I would love
    to have a fully-fleshed example to study it and fully understand it
    to understand if some code maintainability issues.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div style="">
            The problem isn't with Backbone's particular implementation.
            I had the same problems in C++, Java, and with John Resig's
            Simple Inheritance in JavaScript.<br>
            <br>
            The problem isn't with the ES6 implementation. It's the
            whole paradigm.<br>
          </div>
        </div>
      </div>
    </blockquote>
    No, the problem is when people limit the way they think about
    software through this only one paradigm. If this paradigm is here
    alongside others, I don't see the problem. People have the choice.
    Some will make mistakes, but how different is it from today?<br>
    <br>
    David<br>
  </div>

</div><br>_______________________________________________<br>es-discuss mailing list<br><a rel="nofollow" ymailto="mailto:es-discuss@mozilla.org" target="_blank" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br><a rel="nofollow" target="_blank" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a><br><br><br></div> </div> </div>  </div></div></div></div></body></html>