D4mations.com

__proto__ vs prototype – Object Creation in JavaScript P5 – FunFunFunction #52



We explore the __proto__ property on JavaScript Objects, and how it relates to the normal prototype. Basically, the .__proto__ property points to the object that the current object actually will use when doing lookups on the prototype chain, while “.prototype” only exists on functions, in case you want to use those objects as constructors
passed to the new keyword.

# Stuff mentioned in the video:

• Full series: Object creation in JavaScript
https://goo.gl/pCt2tX

• Music in the video: Peacock by 7 minutes dead

# I’m also active on:
• Twitter https://twitter.com/mpjme
• Medium https://medium.com/@mpjme
• Quora https://www.quora.com/profile/Mattias-Petter-Johansson

Original source

d4mer

, , , , , , ,

44 responses to “__proto__ vs prototype – Object Creation in JavaScript P5 – FunFunFunction #52”

  12. this was awesome, and honestly better than the earlier ones. Might be the browser environment and the knowledge build up at this point in the series, but, I think it's a significant improvement.

  13. Hi, So basically, you made it sound like when you use the "new" keyword – you create a copy of an object… and when you use "prototype " or "__proto__" you're essentially making a REFERENCE. I can't really find what the different between a copy of an object (when you use "new" keyword) or a reference to an object(When you use "prototype" or "__proto__"… They practically return the same result… My question here is that when we use copy or reference, are they just for the theoretical purpose, or there's a difference in both… I hope my question makes sense.

  21. You did a great job explaining the difference to me an now I understand however please don't get a job coming up with new names for javascript 🙂 If you named it like that I would have to stop using the language ;P

  27. Great great video! I have learned so much because it's fun watching your videos. My only suggestion is that you use a small whiteboard instead of paper. It seems like an awful lot of paper being used.

  36. Awesome video!

    I wrote this piece of code, but don't exactly understand why the results are the way they are –

    Number.prototype.square = function () {
    let value = this;
    return value * value;
    }
    String.prototype.append = function () {
    return this+' JavaScript Rocks!';
    }

    'hello'.append() yields "hello JavaScript Rocks!"
    new Number(4).square() yields 16
    var i = 4;
    i.square() yields 16.

    But,
    4.square() gives "Uncaught SyntaxError: Invalid or unexpected token"

    The typeof 'i' and 4 is both "number". Kindly explain why this is happening.

    Happy Coding!
    Kaushik.

  37. Well explained, I will use the pen delegation example when I explain prototype to others. You should do an episode about the difference between changing a property value on the prototype object vs changing it on an object with the same prototype. It also confuses a lot of people.

  38. Hello mpj, even I have worked mainly as a software engineer since 23 years, I consider myself as a beginner and very ignorant developer (especially in JS), but I "stay curiouss' even though. I often refer to you as my "programming Guru"
    I appreciate a lot your series and watched Object series from P1 to P5. but I have a st()()pid question:

    I don't precisely grasp the differrence between declaring a "method" directly in the function like that;
    v1: called "methods defined internally" in this article (http://www.phpied.com/3-ways-to-define-a-javascript-class/)
    function Person{ laugh: function{console.log('haha !') }

    or like that
    v2:
    function Person{ }
    Person.prototype.laugh = function{ console.log('haha !') }

    I am not sure but I think reading previously that with the v1, laugh property will be duplicated every time a new Person object is created while its not the case in v2 because laugh is factorized / delegated to Person.prototype

    It also seems that these issues are related with this famous OOP quote 'Inheritance may always be replaced by delegation' (which is illustrated by the "one UML class diagram to rule them all": the class related to itself with a white diamond shape ending edge

    Long time ago I've heard about the "Prototype-instance" paradigm (by contrast with "Class-instance"). JS is a Protytope based programming language right(https://en.wikipedia.org/wiki/Prototype-based_programming) ?

    Also I've been very interested by AOM (Adaptative Object Modelling) where Classes are just "dynamic objects that can be used as templates for new Objects". I've even wrote a "private-joke" prototype "Single Class Object Model" (https://github.com/terimakasi/scom) to satirize the labyrithine nature of the "deep static class hierarchies" and proposing the extreme opposite with a single class on which methods and attributes are dynamycally defined

    Apart from being static, "Class based language" bring another trap: mix two very distinct things:
    1. Delegation: factorization (generic reuse) of attributes/methods
    2. Typing: categorize objects by common profile (same behavior and appearence). Keeping in mind that an object may generally belong to multiples types (ex: a man may be both a Father, a Brother, an Employee, a Friend, an Artist, a Chess player etc)

    Thats why I globally hate Java:
    – Interfaces are great but Classes are crappy (IMHO): I've for a long time been disturbed by these "anonymous classes", then discovered that it was mainly a way to hide the dys-functional nature of Java by encapsulating a function in a class. Because function are not first class citizens in Java (which has been fixed with Java successors like Scala)

    For this reason JS after all may be a better OOP language by encouraging delegation over inheritance and at the same time "saving us" with the crappy "REAL class" entity

Leave a Reply