<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 12.07.2011 0:18, Bob Nystrom wrote:
    <blockquote
cite="mid:CAF8T8LzGHXOZ3y4Pm_FyGBFyyA3QXx3tK3zQkhOh2at1f+UfEw@mail.gmail.com"
      type="cite">
      <div>I agree with Brendan's replies, but just to add some more
        color:</div>
      <div><br>
      </div>
      <div>On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll <<a
          moz-do-not-send="true" href="mailto:anguscroll@gmail.com">anguscroll@gmail.com</a>>
        wrote:</div>
      <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;
        border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
        The concept itself is very simple - a dynamic archetype to be
        shared by all my instances: my prototype changes, my instances
        know about it. I would not want to hide such a smart, simple
        concept behind the more complex and (in this scenario) less
        meaningful concept of class.</blockquote>
      <div><br>
      </div>
      <div>To me, that's pretty close to a "class": a thing that
        describes the properties and behavior of a set of objects. Sure,
        you can roll in all of the other shenanigans that Java et. al.
        include (final, static, nested classes, etc.) but the real
        kernel is "we have a bunch of objects that are similar and we
        want to define that similarity in one place."</div>
      <div><br>
      </div>
      <div>JS does so through MyType.prototype and class-based languages
        do it in a class definition. The class syntax proposal just
        gives you a nicer notation for the former.</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    It turns our that making decisions though the prism of some concrete
    _implementation_, programmers make incorrect judgment about some
    _techniques_ of code reuse. Ideological code reuse "class" may have
    several implementations. In static second-class classes, it can be
    method-calls technique with static (and known) addresses. In
    contrast in first-class dynamic systems it can be message passing
    technique based on delegation (i.e. based on prototypes).<br>
    <br>
    But still, _regardless implementation_, the concept of a class
    assumes just a _classified code_ reuse, no more, no less. That is,
    (1) creation of many instances with the same state, (2) ability to
    mark the instances with the classification tag.<br>
    <br>
    Thus, the (2) is not even required. Once you've started to create
    many instances with the same state -- you already program with the
    concept of a class, i.e. using classified code reuse. E.g.:<br>
    <br>
    var pointA= {x: 10, y: 20};<br>
    var pointB= {x: 30, y: 40};<br>
    var pointC= {x: 50, y: 60};<br>
    <br>
    I already created (in mind, virtually) the concept of a point class.
    That's it.<br>
    <br>
    And all the other stuff -- is just the _syntactic improvements_ of
    this concept. There no other reasons. Just very practical reason --
    efficient code reuse. Don't wanna write this copy-pasted points --
    move them to a function (as you always do, when a code is repeated
    more than two times) -- and you get constructors of JS. Don't like
    that classification is called not with the word "class" -- rename it
    to "class" and add another sugar. So -- just the sugar matters. And
    without the sugar, that's said -- only practical code reuse
    technique.<br>
    <br>
    I hope this small table will help: <a class="moz-txt-link-freetext" href="https://gist.github.com/977034">https://gist.github.com/977034</a>
    Once again -- statics method-calls vs. dynamics and
    delegation/message passing -- are just the techniques. But a "class"
    is a concept, which can be implemented in any form. From this
    viewpoint JS had, have, and will have (sugared now) classes. Because
    a "class" is not a special keyword "class" in a lang, it's not the
    ability to create classes with this keyword, but class -- is _the
    ability to classify_. And how it's done -- either with "class"
    keyword or with the "function" keyword -- absolutely doesn't matter.<br>
    <br>
    P.S.: regarding concept of mixins -- JS (starting form the time,
    when Object.extend was borrowed from Ruby to Prototype.js) has
    currently static mixins with copying own properties. In the same
    Ruby mixins are delegation-based, that is no more than just many
    prototypes mixed to an object -- change a mixed module, and all
    instances which are included the module will see these changes --
    pure delegation.<br>
    <br>
    P.S[1]: the same with Python. Once it has a sugar called "class"
    novices on comp.sci call it class-based. But in fact, Python is
    prototype-based language, i.e. delegation-based with "classes as
    sugar". The same as in CoffeeScript, the same as planned for
    ECMAScript. So there is nothing to scary.<br>
    <br>
    Dmitry.<br>
    <br>
    <blockquote
cite="mid:CAF8T8LzGHXOZ3y4Pm_FyGBFyyA3QXx3tK3zQkhOh2at1f+UfEw@mail.gmail.com"
      type="cite">
      <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;
        border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
        a) The syntax may be fixable but the logic isn't. Inheritance
        hierarchies are gnarly.<br>
        - Nine times out of ten it's a re-use technique masquerading as
        a classification of types.</blockquote>
      <div><br>
      </div>
      <div>
        Agreed, completely. Deep inheritance hierachies are almost
        always a guarantee of misery. But the 1 in 10 case where OOP
        inheritance has been a big success is... UI frameworks.
        Considering how important that use case is to JavaScript,
        supporting it gracefully seems reasonable to me.</div>
      <div><br>
      </div>
      <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;
        border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
        - Mixins allow objects to borrow from an unlimited number of
        other objects regardless of lineage, while still allowing for
        organization of functions by type.</blockquote>
      <div><br>
      </div>
      <div>I'm a huge fan of mixins/traits/multiple-inheritance (<a
          moz-do-not-send="true"
href="http://journal.stuffwithstuff.com/2011/02/21/multiple-inheritance-in-javascript/">http://journal.stuffwithstuff.com/2011/02/21/multiple-inheritance-in-javascript/</a>).
        I very often find single inheritance frustrating.</div>
      <div><br>
      </div>
      <div>I don't like "classic" mixins because they make it too easy
        for a later mixin to stomp over the methods of an earlier one.
        Traits solve that nicely, and I'd like to see them in JS at some
        point. If we had them, I'd use them heavily.</div>
      <div><br>
      </div>
      <div>At the same time, I probably bear the most responsibility for
        talking Mark into taking them out of the class proposal. My
        reasoning was this:</div>
      <div><br>
      </div>
      <div>1. Getting *any* declarative "kind of thing" syntax into JS
        is fantastically hard, as you can see.</div>
      <div>2. We'll need something like that to hang traits/mixins off
        of.</div>
      <div>3. Traits are complex enough that they may sink the whole
        proposal.</div>
      <div><br>
      </div>
      <div>So my take was: start with a simple class syntax that lets
        you declaratively express how JS is being written *right now*
        with single inheritance. If we can get that into ES6, we'll be
        in a much better position to try to work traits into ES7. (And
        even if traits never get in, I think we'll have made a large
        fraction of the world's JS simpler and easier to read.)</div>
      <div><br>
      </div>
      <div>It's also worth remembering that this class proposal doesn't
        take away any of the flexibility JS has. Your mixin system and
        my weird little MI one will still work in an ES6 that has a
        class syntax. It's just that if you're following the common path
        of defining constructor functions and adding functions to its
        .prototype, then you'll have a simpler syntax for doing so.</div>
      <div><br>
      </div>
      <div>We're paving a footpath here, not building a fence around it.
        You're always free to wander off it into the forest.</div>
      <div><br>
      </div>
      <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;
        border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
        Earlier in this thread, Brendan said "I claim we can do little
        to control the outcome in terms of adoption...the classical OOP
        patterning in many devs' brains, count more than our
        exhortations." That's sad because I think many ex-classical
        programmers (myself included) grew tired of implementation
        inheritance as the dominant paradigm and gravitated to
        JavaScript (and also functional languages) as a refuge from the
        stodgy tyranny of bloated hierarchies.</blockquote>
      <div><br>
      </div>
      <div>I too grew tired of implementation inheritance, but not
        classes. I still really like class-based languages, I just like
        ones like Python and C# (and JS if you're loose about "class")
        that augment that with first-class functions and other ways to
        compose behavior.</div>
      <div><br>
      </div>
      <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;
        border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
        JavaScript is on the upward path, Java on the down. We're
        fostering a generation of converts from classical OOP to
        something more elegant, agile and useful. It would be a shame to
        throw in the towel now.</blockquote>
      <div>
        <br>
      </div>
      <div>I think you're making a false dichotomy here. "Classes"
        doesn't always mean Java's "sign everything in triplicate, here
        comes the Carpal tunnel" level of boilerplate. Nor does it
        always mean C++'s "better write a style guide before you
        coworker uses some hideous dark corner of the language" level of
        complexity/flexibility ("comflexibility"?). Consider Smalltalk,
        CLOS, Python, Ruby, or C#. You can have classes in a beautiful
        language.</div>
      <div><br>
      </div>
      <div>- bob</div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
es-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>