davidbgk
/
larlet-fr-david-cache

<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang=fr>
<!-- Has to be within the first 1024 bytes, hence before the <title>
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset=utf-8>
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
<!-- Required to make a valid HTML5 document. -->
<title>JS Objects: De"construct"ion (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/static/david/icons/favicon.ico">
<meta name="apple-mobile-web-app-title" content="David Larlet">
<meta name="application-name" content="David Larlet">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- That good ol' feed, subscribe :p. -->
<link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="http://davidwalsh.name/javascript-objects-deconstruction">

<style>
/* http://meyerweb.com/eric/tools/css/reset/ */
html, body, div, span,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, address, big, cite, code,
del, dfn, em, img, ins,
small, strike, strong, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section { display: block; }
body { line-height: 1; }
blockquote, q { quotes: none; }
blockquote:before, blockquote:after,
q:before, q:after {
  content: '';
  content: none;
}
table {
  border-collapse: collapse;
  border-spacing: 0;
}

/* http://practicaltypography.com/equity.html */
/* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */
/* https://www.filamentgroup.com/lab/js-web-fonts.html */
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');
  font-weight: 300;
  font-style: italic;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'ConcourseT3';
  src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),
       url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}


/* http://practice.typekit.com/lesson/caring-about-opentype-features/ */
body {
  /* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */
  font-family: "EquityTextB", Palatino, serif;
  background-color: #f0f0ea;
  color: #07486c;
  font-kerning: normal;
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: subpixel-antialiased;
  text-rendering: optimizeLegibility;
  font-variant-ligatures: common-ligatures contextual;
  font-feature-settings: "kern", "liga", "clig", "calt";
}
pre, code, kbd, samp, var, tt {
  font-family: 'TriplicateT4c', monospace;
}
em {
  font-style: italic;
  color: #323a45;
}
strong {
  font-weight: bold;
  color: black;
}
nav {
  background-color: #323a45;
  color: #f0f0ea;
  display: flex;
  justify-content: space-around;
  padding: 1rem .5rem;
}
  nav:last-child {
    border-bottom: 1vh solid #2d7474;
  }
  nav a {
    color: #f0f0ea;
  }
  nav abbr {
    border-bottom: 1px dotted white;
  }

h1 {
  border-top: 1vh solid #2d7474;
  border-bottom: .2vh dotted #2d7474;
  background-color: #e3e1e1;
  color: #323a45;
  text-align: center;
  padding: 5rem 0 4rem 0;
  width: 100%;
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
}
  h1.single {
    padding-bottom: 10rem;
  }
  h1 span {
    position: absolute;
    top: 1vh;
    left: 20%;
    line-height: 0;
  }
    h1 span a {
      line-height: 1.7;
      padding: 1rem 1.2rem .6rem 1.2rem;
      border-radius: 0 0 6% 6%;
      background: #2d7474;
      font-size: 1.3rem;
      color: white;
      text-decoration: none;
    }
h2 {
  margin: 4rem 0 1rem;
  border-top: .2vh solid #2d7474;
  padding-top: 1vh;
}
h3 {
  text-align: center;
  margin: 3rem 0 .75em;
}
hr {
  height: .4rem;
  width: .4rem;
  border-radius: .4rem;
  background: #07486c;
  margin: 2.5rem auto;
}
time {
  display: bloc;
  margin-left: 0 !important;
}
ul, ol {
  margin: 2rem;
}
ul {
  list-style-type: square;
}
a {
  text-decoration-skip-ink: auto;
  text-decoration-thickness: 0.05em;
  text-underline-offset: 0.09em;
}
article {
  max-width: 50rem;
  display: flex;
  flex-direction: column;
  margin: 2rem auto;
}
  article.single {
    border-top: .2vh dotted #2d7474;
    margin: -6rem auto 1rem auto;
    background: #f0f0ea;
    padding: 2rem;
  }
  article p:last-child {
    margin-bottom: 1rem;
  }
p {
  padding: 0 .5rem;
  margin-left: 3rem;
}
  p + p,
  figure + p {
    margin-top: 2rem;
  }

blockquote {
  background-color: #e3e1e1;
  border-left: .5vw solid #2d7474;
  display: flex;
  flex-direction: column;
  align-items: center;
  padding: 1rem;
  margin: 1.5rem;
}
  blockquote cite {
    font-style: italic;
  }
  blockquote p {
    margin-left: 0;
  }

figure {
  border-top: .2vh solid #2d7474;
  background-color: #e3e1e1;
  text-align: center;
  padding: 1.5rem 0;
  margin: 1rem 0 0;
  font-size: 1.5rem;
  width: 100%;
}
  figure img {
    max-width: 250px;
    max-height: 250px;
    border: .5vw solid #323a45;
    padding: 1px;
  }
figcaption {
  padding: 1rem;
  line-height: 1.4;
}
aside {
  display: flex;
  flex-direction: column;
  background-color: #e3e1e1;
  padding: 1rem 0;
  border-bottom: .2vh solid #07486c;
}
  aside p {
    max-width: 50rem;
    margin: 0 auto;
  }

/* https://fvsch.com/code/css-locks/ */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
  font-size: 1rem;
  line-height: calc( 1.5em + 0.2 * 1rem );
}
h1 {
  font-size: 1.9rem;
  line-height: calc( 1.2em + 0.2 * 1rem );
}
h2 {
  font-size: 1.6rem;
  line-height: calc( 1.3em + 0.2 * 1rem );
}
h3 {
  font-size: 1.35rem;
  line-height: calc( 1.4em + 0.2 * 1rem );
}
@media (min-width: 20em) {
  /* The (100vw - 20rem) / (50 - 20) part
     resolves to 0-1rem, depending on the
     viewport width (between 20em and 50em). */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );
    margin-left: 0;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
}
@media (min-width: 50em) {
  /* The right part of the addition *must* be a
     rem value. In this example we *could* change
     the whole declaration to font-size:2.5rem,
     but if our baseline value was not expressed
     in rem we would have to use calc. */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * 1rem );
    line-height: 1.5em;
  }
  p, li, pre, details {
    margin-left: 3rem;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * 1rem );
    line-height: 1.2em;
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * 1rem );
    line-height: 1.3em;
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * 1rem );
    line-height: 1.4em;
  }
  figure img {
    max-width: 500px;
    max-height: 500px;
  }
}

figure.unsquared {
  margin-bottom: 1.5rem;
}
  figure.unsquared img {
    height: inherit;
  }


@media print {
  body { font-size: 100%; }
  a:after { content: " (" attr(href) ")"; }
  a, a:link, a:visited, a:after {
    text-decoration: underline;
    text-shadow: none !important;
    background-image: none !important;
    background: white;
    color: black;
  }
  abbr[title] { border-bottom: 0; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  img { page-break-inside: avoid; }
  @page { margin: 2cm .5cm; }
  h1, h2, h3 { page-break-after: avoid; }
  p3 { orphans: 3; widows: 3; }
  img {
    max-width: 250px !important;
    max-height: 250px !important;
  }
  nav, aside { display: none; }
}

ul.with_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_columns {
    column-count: 2;
  }
}
@media (min-width: 50em) {
  ul.with_columns {
    column-count: 3;
  }
}
ul.with_two_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_two_columns {
    column-count: 1;
  }
}
@media (min-width: 50em) {
  ul.with_two_columns {
    column-count: 2;
  }
}

.gallery {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-around;
}
  .gallery figure img {
    margin-left: 1rem;
    margin-right: 1rem;
  }
  .gallery figure figcaption {
    font-family: 'ConcourseT3'
  }

footer {
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
  border-top: 3px solid white;
  padding: 4rem 0;
  background-color: #07486c;
  color: white;
}
  footer > * {
    max-width: 50rem;
    margin: 0 auto;
  }
  footer a {
    color: #f1c40f;
  }
  footer .avatar {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    float: left;
    -webkit-shape-outside: circle();
    shape-outside: circle();
    margin-right: 2rem;
    padding: 2px 5px 5px 2px;
    background: white;
    border-left: 1px solid #f1c40f;
    border-top: 1px solid #f1c40f;
    border-right: 5px solid #f1c40f;
    border-bottom: 5px solid #f1c40f;
  }
</style>

<h1>
  <span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>
  JS Objects: De"construct"ion (archive)
  <time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>
</h1>
<section>
  <article>
    <h3><a href="http://davidwalsh.name/javascript-objects-deconstruction">Source originale du contenu</a></h3>
    <h3>JS Objects: TL;DR</h3>

<p>&#13;
<p>JavaScript has been plagued since the beginning with misunderstanding and awkwardness around its "prototypal inheritance" system, mostly due to the fact that "inheritance" isn't how JS works at all, and trying to do that only leads to gotchas and confusions that we have to pave over with user-land helper libs. Instead, embracing that JS has "behavior delegation" (merely delegation links between objects) fits naturally with how JS syntax works, which creates more sensible code without the need of helpers.</p>&#13;
<p>When you set aside distractions like mixins, polymorphism, composition, classes, constructors, and instances, and only focus on the objects that link to each other, you gain a powerful tool in behavior delegation that is easier to write, reason about, explain, and code-maintain. Simpler is better. JS is "objects-only" (OO). Leave the classes to those other languages!</p>&#13;
&#13;
<h3>Due Thanks</h3>&#13;
<p>I'd like to thank the following amazing devs for their generous time in feedback/tech review of this article series: David Bruant, Hugh Wood, Mark Trostler, and Mark McDonnell. I am also honored that David Walsh wanted to publish these articles on his fantastic blog.</p>&#13;
&#13;
<p>In part 1 of this article series (which you should totally go read if you haven't yet!), I revisited an idea not original to me: <a href="http://davidwalsh.name/javascript-objects">JS doesn't have "inheritance" in the traditional sense</a>, and what it does have is more appropriately labeled "behavior delegation" -- the ability of one object to delegate a method or property access which it <em>cannot</em> handle over to another object which <em>can</em> handle it.</p>&#13;
&#13;
<p>Then, in part 2, I addressed <a href="http://davidwalsh.name/javascript-objects-distractions">several distractions</a> which <strong><em>I think</em></strong> obfuscate JS's true object-oriented identity, including "custom types", "mixins", "polymorphism" (which we'll come back to again later), and even the new "class syntax" coming in ES6. I suggested that to understand (and leverage) better the <code>[[Prototype]]</code>, we needed to strip away the cruft. Here, I will attempt to do that.</p>&#13;
&#13;
<h2><del>Turtles</del> Objects all the way <del>down</del> up</h2>&#13;
<p>The key realization, the punchline to this entire article series, is that <code>[[Prototype]]</code> is really only about linking one object to another object, for the purposes of delegating, if the first object <a href="http://www.ecma-international.org/ecma-262/5.1/#sec-8.12.2">cannot handle a property or method access</a> but the second can. In other words, it's only objects, linked to other objects. That's really all JS has.</p>&#13;
&#13;
<p>In a sense, JS is the purest essence of a "object-oriented (OO)" language, in that it really <em>is</em> all about objects. In contrast to most other languages, JS is somewhat unique that you can actually create objects directly without the notion of classes or other abstractions. That's a powerful and brilliant feature!</p>&#13;
&#13;
<blockquote><p>People often bash JavaScript, but it’s one of the few prog languages that let you directly create objects. Others: Lua, Dylan, Cecil.</p>&#13;
&#13;
<p>— Axel Rauschmayer (@rauschma) <a href="https://twitter.com/rauschma/status/321712221400989696">April 9, 2013</a></p></blockquote>&#13;
&#13;
<p>JavaScript legitimately <em>is</em> "object-oriented", and perhaps we shouldn't have used that term for the other languages which imply a lot more than <strong><em>just</em></strong> "objects". Maybe "class-oriented" would have been more accurate, which would have freed us up to use "object-oriented" for JS. Of course, as I argued in part 1, <a href="http://davidwalsh.name/javascript-objects#spade-spade">what everybody means when they use some term, matters</a>, so it's far too late to redefine or bend the commonly accepted "object-oriented" to my own purposes, much as I'd like to.</p>&#13;
&#13;
<p>I'm mildly tempted, however, to just hijack the abbreviation of "OO" to mean "objects-only" instead of "object-oriented", but I bet that probably wouldn't get anywhere, either. So, for our purposes here, let's just say<strong>JavaScript is "object-based (OB)"</strong> to clarify against "object-oriented (OO)".</p>&#13;
&#13;
<p>Whatever we call it, we normally tap into this object mechanism by following the "OO way": we create a function which we use as a "constructor", and we call that function with <code>new</code> so that we can "instantiate" our "class", which we specify with the constructor function together with its subsequent <code>.prototype</code> additions... but all that is like a magician's sleight of hand that dazzles you <em>over here</em> to distract you from what's really going on <em>over there</em>.</p>&#13;
&#13;
<p>What really matters, at the end of the trick, is that <strong>two objects end up linked to each other via the<code>[[Prototype]]</code> chain</strong>.</p>&#13;
&#13;
<h2>Codez Plz</h2>&#13;
<p>&#13;
Before we can derive and understand that simpler view of "objects-only" or "object-based", we need to understand what actually gets created and linked when we build up some "inherited" objects in JavaScript. Not only are we going to see what happens by default, but what <em>doesn't</em> happen.</p>&#13;
&#13;
<p>Take this code for our main example:</p>&#13;
&#13;
<pre class="js">function Foo(who) {&#13;
    this.me = who;&#13;
}&#13;
&#13;
Foo.prototype.identify = function() {&#13;
    return "I am " + this.me;&#13;
};&#13;
&#13;
function Bar(who) {&#13;
    Foo.call(this,who);&#13;
}&#13;
&#13;
Bar.prototype = Object.create(Foo.prototype);&#13;
// NOTE: .constructor is borked here, need to fix&#13;
&#13;
Bar.prototype.speak = function() {&#13;
    alert("Hello, " + this.identify() + ".");&#13;
};&#13;
&#13;
var b1 = new Bar("b1");&#13;
var b2 = new Bar("b2");&#13;
&#13;
b1.speak(); // alerts: "Hello, I am b1."&#13;
b2.speak(); // alerts: "Hello, I am b2."</pre>&#13;
&#13;
&#13;
<p><strong>Note:</strong> Some people write <code>Bar.prototype = Object.create(Foo.prototype);</code> as <code>Bar.prototype = new Foo();</code>. Both approaches end up with the same linked objects, where <code>Bar.prototype</code> is an object linked via its<code>[[Prototype]]</code> to <code>Foo.prototype</code>. The only real difference is whether or not the <code>Foo</code> function is called during the creation of <code>Bar.prototype</code>. Depending on your circumstances and intent, you may or may not want that to happen, so let's consider them roughly interchangable but with different purposes.</p>&#13;
&#13;
<p>What we have is an object labeled <code>Foo.prototype</code> with an <code>identify()</code> method, and another object called<code>Bar.prototype</code> with a <code>speak()</code> method. <code>Bar.prototype</code> is a <em>new empty object</em> that is <code>[[Prototype]]</code>-linked to <code>Foo.prototype</code>. Then we have two objects <code>b1</code> and <code>b2</code>, who each are each respectively linked via their own <code>[[Prototype]]</code> to <code>Bar.prototype</code>. <code>b1</code> and <code>b2</code> also have an "owned property" directly on each of them called <code>me</code>, which respectively holds the values "b1" and "b2".</p>&#13;
&#13;
<p>Let's take a visual look at the relationships implied by the above code snippet:</p>&#13;
&#13;
<p><a href="http://davidwalsh.name/demo/JavaScriptObjects--Simplified.png" target="_blank"><img alt="" src="http://davidwalsh.name/demo/JavaScriptObjects--Simplified.png"/></a></p>&#13;
&#13;
<p><strong>Note:</strong> All the <code>[[Prototype]]</code> links in the diagram also mention <a href="https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/proto">a ".<strong>proto</strong>" property</a>. <code><strong>proto</strong></code> is a formerly non-standard property (which exists in most but not all JS environments) to expose the internal <code>[[Prototype]]</code>chain. As of ES6, however, it will be standardized.</p>&#13;
&#13;
<p>I left a whole bunch of detail out of that diagram, intentionally, so it was even remotely digestable. But of course, since JS is all objects, all the linkages and ancestry of each item can be fully traced. We'll come back to all the omitted parts of this diagram in a little bit.</p>&#13;
&#13;
<p>Note in this diagram that the function constructors all have a <code>.prototype</code> property pointing at an object. As we've been suggesting, the object is what we really care about, and in this way of viewing the JS object mechanism, the way we get that object is to look at a constructor function's <code>.prototype</code>. The function doesn't really serve any particularly important role.</p>&#13;
&#13;
<p>I know a whole bunch of you just screamed out, "sure it does! it runs constructor code to initialize the new object!" OK, you're technically right. <code>Foo()</code> has some code in it which is ultimately run against <code>b1</code> and <code>b2</code>.</p>&#13;
&#13;
<p>But the devil's always in the details. First, we don't need a constructor function to run such code. That's just one way of getting that outcome. And I'm going to suggest it's a more distracting approach.</p>&#13;
&#13;
<p>Secondly, <a href="http://max.berger.name/teaching/s06/ch13.jsp">unlike C++</a>, the base-class/superclass <code>Foo()</code> "constructor" doesn't automatically get called when you run the child-class <code>Bar()</code> "constructor" to make <code>b1</code> and <code>b2</code>. So, like Java, we have to manually call the<code>Foo()</code> function from <code>Bar()</code>, but unlike Java, we have to do so with a variation of the <a href="http://davidwalsh.name/javascript-objects-distractions#mixins">explicit "mixin" pattern</a> (I'd probably call it "implicit mixin" here) to make it work like we expect. That's an ugly detail that is very easy to forget or get wrong.</p>&#13;
&#13;
<p>So, where you'd probably argue with me that "constructor" functions are useful being automatically called at the construction of an object, I'd point out that this is true for only the immediate level, not for the entire "chain of inheritance", which means that automatic behavior is pretty limited/shallow in utility.</p>&#13;
&#13;
<h2>Polymorphism redux</h2>&#13;
<p>Moreover, we see here the first hint of the <a href="http://davidwalsh.name/javascript-objects-distractions#polys">problems with relative polymorphism</a> in JS: <strong>you can't do it!</strong> I can't tell<code>Bar()</code> to automatically and relatively call his ancestor constructor(s), via a relative reference. I have to manually call (aka, "borrow") the <code>Foo()</code> function (it's not a constructor here, just a normal function call!) from inside of<code>Bar()</code>, and to make sure the <code>this</code> is bound correctly, I have to do the slightly more awkward <code>.call(this)</code>style of code. Ugh.</p>&#13;
&#13;
<p>What may not be obvious until you go back and look closer at the diagram above is that the <code>Foo()</code> function is<strong>not</strong> related in any useful/practical way to the <code>Bar()</code> function. The <code>Foo()</code> function does not even appear in the "inheritance" (aka "delegation") chain of <code>Bar.prototype</code> object. The fact that there are some lines you can follow on the graph for indirect relationships doesn't mean that those relationships are what you'd want to rely on in your code.</p>&#13;
&#13;
<p>The problem with polymorphism we're seeing here is not only for "constructor" functions. Any function at one level of the <code>[[Prototype]]</code> chain that wants to call up to an ancestor with the same name must do so via this manual implicit mixin approach just like we did inside of <code>Bar()</code> above. <strong>We have no effective way of making relative references up the chain.</strong></p>&#13;
&#13;
<p>Importantly, this means that not only do we establish the link between <code>Bar</code> and <code>Foo</code> once at "class" definition, but every single polymorphic reference also has to be hardcoded with the direct relationship. This significantly decreases the flexibility and maintainability of your code. As soon as you make a function hard-coded with implicit mixin to an "ancestor", now your function can't be "borrowed" as easily by other objects without those possible unintended side effects.</p>&#13;
&#13;
<p>OK, so let's say you agree with me at this point that polymoprhism in JS is more trouble than it's worth. <strong>Using constructor-based coding to wire JS objects to each other forces you into the <em>problems</em> of polymorphism</strong>.</p>&#13;
&#13;
<h2>.constructor</h2>&#13;
<p>Another detail that's easy to miss is that an object's <code>.constructor</code> property really doesn't behave like we'd probably expect. It's correct at the <code>Foo()</code> level of the graph, but below that, at <code>Bar()</code> and <code>b1</code> / <code>b2</code>, notice that the implied linkage there shows <code>.constructor</code> references, strangely, still pointing at <code>Foo</code>.</p>&#13;
&#13;
<p>Actually, what this means is that the only time a <code>.constructor</code> property is added to an object is when that object is the <strong>default</strong> <code>.prototype</code> attached to a declared function, as is the case of <code>Foo()</code>. When objects are created via <code>new Fn()</code> or <code>Object.create(..)</code> calls, those objects <strong>don't</strong> get a <code>.constructor</code> added to them.</p>&#13;
&#13;
<p>Let me say that again: an object created by a constructor doesn't actually get a <code>.constructor</code> property to point to which constructor it was created by. This is an <strong>extremely common</strong> misconception.</p>&#13;
&#13;
<p>So if you reference <code>b1.constructor</code> for instance, then you're actually going to delegate up the chain a few links, to <code>Foo.prototype</code>. Of course, <code>Foo.prototype</code> has a <code>.constructor</code> property and it's pointing at <code>Foo</code> like you'd expect.</p>&#13;
&#13;
<p>What's that mean? In the above snippet, right after you perform <code>Bar.prototype = Object.create(Foo)</code> (or even if you'd done <code>Bar.prototype = new Foo()</code>), if you plan to rely on the <code>.constructor</code> property (which many do), you need to perform an extra step, right where I put the JS "Note:" comment:</p>&#13;
&#13;
<pre class="js">//...&#13;
Bar.prototype = Object.create(Foo.prototype);&#13;
Bar.prototype.constructor = Bar; // &lt;-- add this line!&#13;
//...</pre>&#13;
&#13;
<p>Then <code>b1.constructor</code> references will delegate to that <code>Bar.prototype</code> level, and will "correctly" point at <code>Bar()</code>as you'd probably have expected. Ugh...<strong>more syntax gotchas</strong> that user-land libs always have to "fix" for us.</p>&#13;
&#13;
<p>Furthermore, the fact that <code>Foo.prototype</code> has a <code>.constructor</code> property pointing at <code>Foo</code> is strange, when you think about "constructor" the way most people do. It's nice that it gives objects created by <code>new Foo()</code> a way to delegate to a <code>.constructor</code> property access and find <code>Foo()</code>, but it's bizarre where <code>.constructor</code> actually lives.</p>&#13;
&#13;
<p>It implies that <code>Foo()</code> constructed <code>Foo.prototype</code>, but that's nonsense. <code>Foo()</code> had nothing to do with creating the default <code>Foo.prototype</code>. <code>Foo.prototype</code> defaults to an empty object that was <strong>actually constructed by the built-in <code>Object()</code> constructor</strong>.</p>&#13;
&#13;
<p>So we have to change how we think of what the <code>.constructor</code> property means. It does <strong>not</strong> mean "the constructor this object was created by". It <em>actually</em> means "the constructor which creates any objects that end up getting <code>[[Prototype]]</code> linked to this object." Subtle but super important difference to get straight.</p>&#13;
&#13;
<p>Point? These confusions only happen/matter if you're using constructor-style code, so it's <em>the choice of this style of code</em> that opts you into the problems. You don't <strong><em>have</em></strong> to live with that pain. There's a better, simpler way!</p>&#13;
&#13;
<h2>The Whole Pie</h2>&#13;
<p>Now let's look at everything that's actually implied by the above snippet of code. Ready for the whole messy thing?</p>&#13;
&#13;
<p><a href="http://davidwalsh.name/demo/JavaScriptObjects--Full.png" target="_blank"><img alt="" src="http://davidwalsh.name/demo/JavaScriptObjects--Full.png"/></a></p>&#13;
&#13;
<p>Take a few minutes to just take all that in. Why show you such a complex diagram?</p>&#13;
&#13;
<p>This diagram actually shows you where some of JavaScript's functionality comes from, where before you might have just never considered how it all worked. For instance, have you wondered how all functions are able to use behavior such as <code>call()</code>, <code>apply()</code>, <code>bind()</code>, etc? You may have assumed each function has that behavior built-in, but as you can see from this diagram, functions <strong>delegate</strong> up their <code>[[Prototype]]</code> chain to handle those behaviors.</p>&#13;
&#13;
<p>While the behavior delegation part is sensible and useful, consider all the <em>implied complexity</em> of constructor-style coding as visualized here. It's pretty tough to trace all the different entities and diagrams and make much sense of it all. A lot of that complexity comes from the function constructors. (here's the same <a href="https://dl.dropboxusercontent.com/u/2474669/jsdiagrams/JavaScript%20Objects%20--%20Full%20--%20Direct%20Only.png">complete graph but with the implied relationship lines omitted</a>, if that helps to digest)</p>&#13;
&#13;
<p>If you take that diagram, and remove all the functions and any associated arrows (which we'll see in just a moment), you're left with "objects-only", and you'll have a <strong>much</strong> more simplified view of the JS objects world.</p>&#13;
&#13;
<h1 id="simpler-object-object">Simpler: Object -&gt; Object</h1>&#13;
&#13;
<blockquote><p>Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. --Antoine de Saint-Exupery</p></blockquote>&#13;
<p>For refresher, the same prototype-style code from above:</p>&#13;
&#13;
<pre class="js">function Foo(who) {&#13;
    this.me = who;&#13;
}&#13;
&#13;
Foo.prototype.identify = function() {&#13;
    return "I am " + this.me;&#13;
};&#13;
&#13;
function Bar(who) {&#13;
    Foo.call(this,who);&#13;
}&#13;
&#13;
Bar.prototype = Object.create(Foo.prototype);&#13;
// NOTE: .constructor is borked here, need to fix&#13;
&#13;
Bar.prototype.speak = function() {&#13;
    alert("Hello, " + this.identify() + ".");&#13;
};&#13;
&#13;
var b1 = new Bar("b1");&#13;
var b2 = new Bar("b2");&#13;
&#13;
b1.speak(); // alerts: "Hello, I am b1."&#13;
b2.speak(); // alerts: "Hello, I am b2."</pre>&#13;
&#13;
<p>Now, let's instead consider this alternative snippet of code, which accomplishes exactly the same, but it does so without any of the confusion/distraction of "constructor functions", <code>new</code>, <code>.prototype</code>, etc. It just creates several objects and links them together.</p>&#13;
&#13;
<pre class="js">var Foo = {&#13;
    init: function(who) {&#13;
        this.me = who;&#13;
    },&#13;
    identify: function() {&#13;
        return "I am " + this.me;&#13;
    }&#13;
};&#13;
&#13;
var Bar = Object.create(Foo);&#13;
&#13;
Bar.speak = function() {&#13;
    alert("Hello, " + this.identify() + ".");&#13;
};&#13;
&#13;
var b1 = Object.create(Bar);&#13;
b1.init("b1");&#13;
var b2 = Object.create(Bar);&#13;
b2.init("b2");&#13;
&#13;
b1.speak(); // alerts: "Hello, I am b1."&#13;
b2.speak(); // alerts: "Hello, I am b2."</pre>&#13;
&#13;
<p>Let's try to take some comparison looks between this snippet and the previous one. They both accomplish the same thing, but there's some important differences in how we get there.</p>&#13;
&#13;
<p>First of all, <code>Bar</code> and <code>Foo</code> are now <strong>just objects</strong>, they're not functions or constructors anymore. I left them as capital letters just for the symmetry and because some people feel better with them. They make it clear that the objects being linked are what we cared about all along, so instead of the indirectness of linking <code>Bar.prototype</code> to<code>Foo.prototype</code>, we just make <code>Foo</code> and <code>Bar</code> objects themselves and link <em>them</em>. <strong>AND</strong>, we only need one line of code to link them, instead of the extra ugly polymorphic linkage. Bam!</p>&#13;
&#13;
<p>Instead of calling function constructors like <code>new Bar(..)</code>, we <a href="https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/create">use <code>Object.create(..)</code></a>, which is an ES5 helper that allows us to create a new object and optionally provide another object to <code>[[Prototype]]</code> link it to. We get the same outcome (object creation and linkage) as a constructor call, but without needing the constructor. BTW, there's a <a href="https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/create#Polyfill">simple non-ES5 polyfill</a> for <code>Object.create(..)</code>, so you can safely use this style of code in all browsers without concern.</p>&#13;
&#13;
<p>Secondly, notice that because we're not worried about constructors anymore, we have eliminated any concerns about awkward polymorphisms forcing us to do manual implied mixins to call <code>Foo()</code> from <code>Bar()</code>. Instead, we put the code we wanted to run to initialize our objects into a <code>init()</code> method, on <code>Foo</code>, and we can now call<code>b1.init(..)</code> directly via the delegation chain and it "magically" just works like we want.</p>&#13;
&#13;
<p>So, we have a tradeoff here. We don't get automatic constructor calls, which means we create the object like<code>var b1 = Object.create(Bar)</code> and then we have to additionally call <code>b1.init("b1")</code>. That's "more code".</p>&#13;
&#13;
<p>But the benefits we get, <strong>which I think are much better and well worth it</strong>, are no awkwardness with the linkage between <code>Foo</code> and <code>Bar</code> -- instead we leverage <code>[[Prototype]]</code> delegation to get at the code reuse in<code>init()</code>. Also, no more verbose/repetitive <code>.prototype</code> references, and neither do we need to use<code>.call(this)</code> nearly as often (especially if we <strong>avoid</strong> polymorphism!).</p>&#13;
&#13;
<h2>Looks are everything</h2>&#13;
<p>And to visualize the simplicity this approach brings us, here's the diagram when we remove the functions entirely and focus only on the objects:</p>&#13;
&#13;
<p><a href="http://davidwalsh.name/demo/JavaScriptObjects--OnlyObjects.png" target="_blank"><img alt="" src="http://davidwalsh.name/demo/JavaScriptObjects--OnlyObjects.png"/></a></p>&#13;
&#13;
<p>I don't know about you, but I just think that mental model is <strong>so much cleaner</strong>, and the bonus is that its semantics perfectly match the code.</p>&#13;
&#13;
<p>I have shown you simple enough code using only core JS syntax, that I don't need any helper libraries to wire up my objects. Of course, I <em>could</em> use one, but why? Simpler is better. KISS.</p>&#13;
&#13;
<blockquote><p>Any fool can make something complicated. It takes a genius to make it simple. --Woody Guthrie</p></blockquote>&#13;
<p>For the record, I'm not <em>even remotely</em> the genius here. <a href="http://twitter.com/brendaneich">Brendan Eich</a>, creator of our language, was the genius for making something so powerful yet so simple.</p>&#13;
&#13;
<h2>Object self-reflection</h2>&#13;
<p>Last thing to address: how does this simplification affect the process of reflecting on an object? In other words, can we inspect an object and find out about its relationships to other objects?</p>&#13;
&#13;
<p>For prototype-style code, reflection looks like this:</p>&#13;
&#13;
<pre class="js">b1 instanceof Bar; // true&#13;
b2 instanceof Bar; // true&#13;
b1 instanceof Foo; // true&#13;
b2 instanceof Foo; // true&#13;
Bar.prototype instanceof Foo; // true&#13;
Object.getPrototypeOf(b1) === Bar.prototype; // true&#13;
Object.getPrototypeOf(b2) === Bar.prototype; // true&#13;
Object.getPrototypeOf(Bar.prototype) === Foo.prototype; // true</pre>&#13;
&#13;
<p>Notice that you're using <code>instanceof</code> and having to think in terms of the constructor functions that made your objects, and their <code>.prototype</code>s, rather than just reflecting on the objects themselves. Each of those reflections comes with slightly more mental tax as a result.</p>&#13;
&#13;
<p>And when there's only objects?</p>&#13;
&#13;
<pre class="js">Bar.isPrototypeOf(b1); // true&#13;
Bar.isPrototypeOf(b2); // true&#13;
Foo.isPrototypeOf(b1); // true&#13;
Foo.isPrototypeOf(b2); // true&#13;
Foo.isPrototypeOf(Bar); // true&#13;
Object.getPrototypeOf(b1) === Bar; // true&#13;
Object.getPrototypeOf(b2) === Bar; // true&#13;
Object.getPrototypeOf(Bar) === Foo; // true</pre>&#13;
&#13;
<p>By contrast, reflection on objects is only about the objects. There's no awkward references to a constructor's<code>.prototype</code> property for the checks. You can just inspect if one object is related via <code>[[Prototype]]</code> to another object. Same capabilities as above, but with less mental tax.</p>&#13;
&#13;
<p>Moreover, as I mentioned in part 2, this sort of explicit object reflection is preferable and more robust/reliable than implicit detection through <a href="http://en.wikipedia.org/wiki/Duck_typing">duck typing</a>.</p>&#13;
&#13;
<h2>Object.wrapItUpAlready()</h2>&#13;
<p>Take a deep breath! That was a lot to take in. If you've followed all 3 parts of the article series, I hope by now you see the bottom line: JS has objects and when we link them, we get powerful behavior delegation.</p>&#13;
&#13;
<p>There's just no need to pile on class-orientation on top of such a great system, because it ultimately just leads to the confusion and distraction that has kept JS' object mechanism shrouded and covered up by all these helper libraries and misunderstandings about JS syntax.</p>&#13;
&#13;
<p>If you stop thinking about inheritance, and instead think with the arrows headed the other way: delegation, your JS code will be simpler. Remember: it's just objects linked to objects!</p></p>
  </article>
</section>


<nav id="jumpto">
  <p>
    <a href="/david/blog/">Accueil du blog</a> |
    <a href="http://davidwalsh.name/javascript-objects-deconstruction">Source originale</a> |
    <a href="/david/stream/2019/">Accueil du flux</a>
  </p>
</nav>

<footer>
  <div>
    <img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">
    <p>
      Bonjour/Hi!
      Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>
      Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).
    </p>
    <p>
      Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.
    </p>
    
    <p>
      Voici quelques articles choisis :
      <a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,
      <a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,
      <a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,
      <a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,
      <a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,
      <a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,
      <a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,
      <a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,
      <a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,
      <a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,
      <a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,
      <a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,
      <a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,
      <a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,
      <a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,
      et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>
    </p>
    <p>
      On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.
    </p>
    <p>
      Je ne traque pas ta navigation mais mon
      <abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>
      conserve des logs d’accès.
    </p>
  </div>
</footer>
<script type="text/javascript">
  ;(_ => {
    const jumper = document.getElementById('jumper')
    jumper.addEventListener('click', e => {
      e.preventDefault()
      const anchor = e.target.getAttribute('href')
      const targetEl = document.getElementById(anchor.substring(1))
      targetEl.scrollIntoView({behavior: 'smooth'})
    })
  })()
</script>