Mattias, you are so fun to watch man, I mean this in a good way, I love your spirit about programming, I am a juniorDev and I really learn stuff from you .. please keep it on/up. oh! and please make an episode all about #RegExp
After programming many years I finally conclude that prototypes are better than classes, not only because of its simplicity but mainly because you can emulate classes with prototypes, but you can't emulate prototypes with classes
I think it would have been a nice illustration if you also added prarieDog.talk() at the end of the exercise. Thanks for these videos, I really enjoy them.
Now this is how u explain prototype chain. Good stuff. It would be even better if u made an empty object wildDog = {}, then Object.setPrototypeOf(wildDog, dog) and then called wildDog.talk() that would be the 'full' proto chain example cause it would call talk up from animal and sound from dog.
I would love this series to cover Object.assign, which I first discovered in the Composition vs Inheritance video. Some more examples of how this is useful would be greatly appreciated. And thanks for all the knowledge so far, you really know how to cut through my confusion 🏆
Reading about pre&post 2015 classes + prototypes made me feel like I gained 40 IQ and a new philosophical outlook on how machines will take us over in the future. Thanks fun fun function
I think an easier approach would have been to show class extensions with prototypes instead of extensions of Objects. Basically prototypes is what you use in Ecmascript 5 when you want to extend a class (you can use it instead of the class name in ecma2015 instead also). Object.setPrototypeOf was interesting to see used on Objects. Haven't really considered that before. Great vid as always funfunfunction.
I would go forward to use prototypes instead of usual classes (like in all other languages not necessarily in js). Imagine you are trying to build an online shop for pets (not sure if legal). You will probably make a initial object "animal" with price and sound. Then you will make dog object which will have a boolean property "hasFleas" and in the case of the video sound set to "woof". But nobody goes to the pet shop saying "One dog please!" so you will have to make objects with breeds. Each breed's prototype will be the "dog" object. Then you can add different characteristics to each breed (properties). So there it is! That's how I understood the concept. I could be somewhat wrong as well as right. Would be nice to see more explanations to see if I messed that up. Good luck! :D
one not probably not obvious comment about THIS: so "console.log(this)" will always point on current object but "console.log(this.sound)" in case where it does not exist in current object will be found inside of parent object or in the prototype itself
Hey MPJ, I *love* your videos. OK, I followed ALL of this up until you redefined the talk function... the dog sound updated to the 'teapot' text... why didn't the prairieDog sound? If its following the prototype chain up, shouldn't it have seen and used the updated talk function, too?
It feels like every prototype tutorial online uses the same super basic example, that never really shows the usefulness or real life application of prototypes. Your delegate analogy was great at the beginning but then it was just 15min of basically repeating the same thing. I'd really love to see this expanded upon to really show, how and especially when you should use prototypes in real life to make your life easier.
+Man Kind well, this was the basics. ;) I repeat the same thing over and over in different ways because I've found that it's really hard to get how this works. But I agree with you that there needs to be some real-world examples of the prototype somewhere along the lines. Not sure if it's for this series though, as I intend this to be an overview of object creation in general, not a deep dive in prototypal inheritance.
Man Kind Prototypes basically allows you to add attributes and methods to an object on the fly without the need to rebuild the object from scratch everytime like in a class object. Like in a usual class object a cat would have all the properties of a mammalian feline. But with a prototype object you can give the cat bat wings cause why not?? :p But then you'll still be wondering how this is useful. Well since in Javascript everything inherits from the Object and thus everything in Javascript is built with prototypes. You're now like yes I know this so how is this useful? :-) It's useful cause you can tack on functionality to objects that never had any intention to have such a feature! You could make sound paint an image. You could make texts count things. You could make a cat bark. Cause then you'd be questioning can't I already do these with classical inheritance?? Well no cause classical inheritances goes down like a tree while prototypes is like an agglutinative language. You can just pile stuff on top of it to do things without any worries what class or category it should belong to! 😁 It's a very cool concept and you could do some crazy things since theres no restrictions. It's why to prevent such freedoms Javascript have a strict token so programmers won't misbehave 😃
Thanks for making our mondays better =D. Can you please add a fiddle when you're explaining things to a real-world example. I do get the explanation but I can't find where does this fit in a real application.
And for those who want a proof that ES6 classes are actually prototypes, then consider the following: class Square { constructor(height, width) { this.height = height; this.width = width; } } function Person(name) { this.name = name; } console.log(typeof Square) //outputs "function" console.log(typeof Square === typeof Person) // outputs "true"
18:00 "setPrototypeOf is never used in real applications" What do you use instead? Object.create?
8 лет назад+1
Great video, as always. But I'm confused by what you did not say: prarieDog says 'WOOF!', even after replacing animal's talk property (and prarieDog's talk does not exist, so it should look into dog prototype for talk, not finding it there, it should look in animal's prototype; obviously I'm wrong somewhere)
So what I understand is that prototype is like a asking a project manager to do something that he can't do himself and he says ok, then passes it on to the person that has that skill in his team to get the work done.
I think of the prototype stack like css inheritance. If a style is not found for the class, then what about the div. If not the div, then what about the body. If not the body, then what about *.
The talk function towards the end should not be garbage collected because it could possibly be assigned dynamically later in the program ( I think) , right?
In short, prototype is a way of implementing inheritance between two objects, one being the base object and another being the one inheriting the properties of the base object. Do I make sense?
Are prototypes primarily a memory optimisation? Rather than defining push on every array instance, it is defined once on Array.prototype and every array points to Array.prototype.
hi, your episodes are really good.. javascript is really different language... there is more talk about progressive web apps.. in future can you make it some small about this term..
I love your videos! One question about this one - why are you using keyword `let` to initiate objects? They are not being reassigned, right? Why not const in this case?
To bring this all together, could you do a vid using prototypes to model the DOM in JS? The examples with traversing up the prototype chain for data makes sense, but the interaction of prototyped functions and instance data isnt. Great vids. Thx!
I loved the part where you said... why don't you marry prototypes. :). Please mpj, i would like to know which softwares you use for your web series. I would like to start a video series soon and I'm looking for some tips.
It seems like prototypes would be heavier on your processor whereas object inheritance would be heavier on memory usage. Is there any significance with larger objects?
+BlueEagle there is only one kind of inheritance built into JavaScript and that is prototype inheritance. Any kind of inheritance will need to be built in top of prototype like inheritance, or have some kind of custom solution implemented. If you build something on top of the prototype model it will have extremely similar memory characteristics unless you make a mistake somewhere.
+Brian Coates (Gamers 4 Life) I have no clue. I was so happy to find it for this episode, because it makes it a lot easier to explain the prototype, but I have clue when you'd use it in production code.
I think what I'm trying to say is how would you implement prototypes into code today if you don't use prototype of to create a relationship what do you use? Hope that makes more sense.
Prototypical inheritance is like you loosing your pen in a class, then you first ask your friends if they have an extra, if they don't, then you ask your 'non-friends', before you then ask your enemies. :)
Not quite. It's like you losing your pen and you ask your friend (you have only one) if they have an extra. If they don't they ask _their_ friend (they have only one) if they have an extra. And if _they_ don't they ask _their_ friend (they have only one), and so on. Until either you have your pen, or run out of friends of friends.
The distinctions are quite critical 1) relationships between classes should never mutate; you don't ask your non-friends or enemies. 2) it's easiest to think of the request being passed to a new actor rather than thinking that the first actor changes their request and 3) prototypal inheritance as it's implemented in ECMAScript does not support multiple inheritance so it's never possible to ask more than one friend. A better example might be passing a note to the person behind you, asking for a pen, then that person passes the note to the person behind them. The relationship between person A and person B is the same as the relationship between B and C (but different from the relationship between A and C) and the note can only be with one person at a time.
I guess it's more accurate if you flip that analogy upside-down. You are the "pen-holder" in your class, (the prototype). Whenever any of your friends need to write something down they have to ask you for the pen. Or, taken even further: You can't give them the pen; they have to tell you what to write and where to write it, and you write for them.
Thank you for the tutorial, i really like it but i think cats and dogs will not be practical way to learn prototypes lets build something practical that uses these concepts.
Love your stuff I'm a great fan. At 2:13 that symbol you make actually means "f off" over here in England, but from reading the comments here I'll imagine you do mean that to some people!
Hello MPJ, you have made some arguments against inheritance in favor of composition. I would like to know if those same arguments apply to prototyping as well. Thank you for your videos, they are very helpful! :)
I suppose that before you set the cat to have the prototype of animal it already had a prototype which was the global erhm...prototype? And as you pointed out a few seconds before the global prototype doesn't have a talk function. So if you then call the cat.poop() function neither the cat, the animal nor the global prototype will have it. Correct?
@10:19 You assign object 'cat' the prototype of another object 'animal'. If only functions have prototypes, I don't understand how it's possible to assign one object, the prototype of another object?
Functions don't only have prototypes, prototypes are a property of objects in general, and functions are a type of object. Also you reassign the prototype of an object just like you can reassign any variable, but with object functions like Object.apply(), or Object.create(). this just adds or reassigns the scope that object has access too. So when MPJ adds to/reassigns an object's prototype-with setPrototypeOf()-, when before he called talk() it threw an error now it will have access to a scope with a talk method. Disclaimer I am self taught but that should be accurate information if I explained myself well enough.
Thanks Colin. I was getting confused between __proto__ and .prototype. Since you mentioned you are self taught, I am as well, and I'm wondering if everyone else might be as well. It doesn't seem like javascript is actually taught in schools, at least never mentioned if it is. If this is the case, it probably would save people a lot of time because javascript is not what it appears to be, when you are first exposed to it, and it takes a while.. months, to figure that out on your own. Then depression sets in, having to relearn something you were already comfortable with.
It can be depressing but if you focus on project creation and let your learning of a subject be based on if it is needed to finish said project, you will have more tangible success. You have probably made a very long journey just make sure you are creating things even if it is a calculator.
While I am 100% comfortable with classes in Java, they seem to just add more stuff to the pile in JS which is not really needed. As you say, one still has to understand the prototype. So what is the purpose then? To trick certain programmers to think that they know JS?
Great video! When creating objects, I love to use "__proto__" property, e.g. "dog = {sound: 'woof', __proto__: animal}" because it makes the code shorter. Isn't it good or bad? What's your opinion?
From a purely semantic standpoint I really like it because it's really clean and more in line with how protoypes actually are, but unfortunately, like setProtoypeOf, it has horrible performance characteristics isn't really advisable in actual apps. See: developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/proto
I know that changing object prototype (by calling Object.prototype.setPrototypeOf or assigning Object.prototype.__proto__) is expensive, and what Object.prototype.__proto__ setter does is calling Object.prototype.setPrototypeOf. But I still think "__proto__" in object literal (object initilization) is not "Object.prototype.__proto__" (object assignment). To demonstrate my assumption, I create a property setter for Object.prototype: gist.github.com/KSXGitHub/a740a7366533306ec65fb9c9ce1a81a2 Moreover, I personally wouldn't care much about performance when code in JavaScript. If I concern about performance, I choose C++, or Python at least.
Sorry, my native language is not English, but when I was first learn prototype, I was confused with a word protoss( A race in Starcraft, which is made by a company call Blizzard). My gut tell me that it maybe has some realtionship with it...One day, Ah ha! If you have played that, you will understand my example: let's say you choose terrain for example. ok, you build a factory to generate marines. this factory can be treat as a Object that has marine prototype. and this Object can generate marines. And each marine initilize with a attack and defence properties, and equeals to 1. This is very important for me to understand prototype, Why? Becasue, the properties which the marine has will be upgrade in the future. that's why I using this case for example. During the game, you might want to upgrade the amys attack proterties. When the research complete. All the marines of you amy, will be upgraded, not only for the marines that hasn't created, but also for the marines that has created. if we don't set the properties on prototype, this will only effected on the marines that will create in the futures, not for created marines. So you will think this is not fair. you should research the attack first, then, create marines...if you do want game to be like this. you just need upgrade the factory marine prototype. This is the case always in my mind....haha...My life for Aiur!
Great video, but to be honest, Fuck prototypes, at least in ES5/6. They are way slower, and heavier than `new`. Hell, even the actual implementation of Object.create uses `new`. I just spent last week trying to get them to stop giving me an entire Jungle, that has a banana tree, that has a banana, when I use Gorilla.eat(banana); To those interested I found 2 strategies for Object creation outside Object.create. 1.) Use a constructor function ( var/let Fn = function()), then attach a new prototype, passed as an param, or bound with (.bind(Proto)), and set the older prototype to Fn.prototype.parent, but this still comes with all the baggage of prototypes. 2.) Use a combo of new and Constructor to return a Factory which allows you to have multiple constructors with bindable protos if you wish through bind or call or apply or whatever. This allows us to separate construction and initialization and the initialization can be deferred to multiple constructors. This also uses closure to instantiate the Object. var Proto = { hammer: function(everything, isANail) { var Hammer = this; Hammer.bang = 'bong'; return Hammer }, pliers: function() { var Pliers = this; Plier.pull = 'fingernails' return Pliers } } Objects.produce = function buildFactoryFromProto(proto, subclass) { var Product = new proto(); if(subclass && typeof(subclass) === 'string' && Product[subclass]) { return (Product[subclass]); // RETURNS CLOSURE INSTANCE } return (Product); // RETURNS CLOSURE INSTANCE } var tools = Objects.construct(Proto); // Factory var pliers = Objects.produce(Proto, 'pliers'); // Factory With Constructor Fn Returned var hammerhead = Objects.produce(Proto)['hammer'](42, 'Nails'); // Factory made, Returning A Constructor Fn we call var hammertime = tools['hammer']('Ohohohoh', 'Stop'); // Tools Factory Returns Hammer Constructor Fn we call
Thanks for clarifying. Would you use .setPrototypeOf in production? Looking for examples that you'd actually in production. Love the vids btw. I've learnt loads since finding you a few months ago. When are you coming to the UK to speak/tour?
Great video as usual! When you're talking about chaining I think you missed to use prarieDog.talk() to show how it's accessing the prototype of the prototype.
Thanks for the video :) So the only difference between class inheritance found in a language like Java and prototype inheritance is that in prototype inheritance you always inherit from object(s) itself, but everything else is the same?
This might be a bit too blunt but it is a good way to keep them separated in your mind. Javascript: the good parts has a good explanation about the difference between class-based and prototype-based languages and that's the core of it.
So it's kind of like a kid standing in front of his parent? The kid will answer every question he can but if he can't answer he'll look over his shoulder and hope that his mum can answer for him?
It's more the other way around. A proxy is generally something that is accessed _first_, sitting _in front_ of the real thing you want to do. You call the proxy, and the proxy calls the object. A prototype sits _behind_. You call the object, the object can't find what you're looking for, so it calls its prototype. Like a safety net if a property access falls through.
Think about it in a way an event propagation works - it worked for me to understand it that way. When you have nested elements the event will bubble up until it finds that particular definition on an element. Similar with prototype, the search will "bubble up" in the prototype chain until a method called is(not) found.
The analogy of the Delegate has really helped cement in my mind, what the prototype really is. Thank you.
Also reason 3 to know about prototype is that you will likely have to work with code at some point that uses it.
No semicolons were harmed during the making of this video.
I don't know about the accuracy of that delegate analogy but everything else was spot on
"Why don't you marry that prototype?"
well, actually I did and we're really happy!
I loved that line too
Must of been just your "type"
Mattias, you are so fun to watch man, I mean this in a good way, I love your spirit about programming, I am a juniorDev and I really learn stuff from you .. please keep it on/up.
oh! and please make an episode all about #RegExp
regexp series would be nice
This a mind bending explanation, "...don't try bend the spoon, instead, think, there is no spoon!"
"I'm doing this to get you out of the class mindset." Jokes on you, I don't know anything about the class concept.
Thanks a lot MPJ for this video!
I wish I could have found an explanation as simple and clear sooner. Great job ;)
I'm so excited to see his talk at BrazilJS. You motivated me to go.
After programming many years I finally conclude that prototypes are better than classes, not only because of its simplicity but mainly because you can emulate classes with prototypes, but you can't emulate prototypes with classes
Thanks for including the examples at the very end that show how prototypes differ from classes (cannot change blueprints dynamically!)
I think it would have been a nice illustration if you also added
prarieDog.talk()
at the end of the exercise.
Thanks for these videos, I really enjoy them.
Your explanations and analogies just click. Thank you!
Thanks for this episode, eventually I could get some idea about prototypes.
Now this is how u explain prototype chain. Good stuff.
It would be even better if u made an empty object wildDog = {}, then Object.setPrototypeOf(wildDog, dog) and then called wildDog.talk() that would be the 'full' proto chain example cause it would call talk up from animal and sound from dog.
By far you are the easiest to listen to. Thanks for being entertaining and not speaking in a thick indian accent.
I think that the class keyword was added on ES6 for the code to be more clean, what is a huge benefit, but in the core is just syntactic sugar!
I would love this series to cover Object.assign, which I first discovered in the Composition vs Inheritance video. Some more examples of how this is useful would be greatly appreciated. And thanks for all the knowledge so far, you really know how to cut through my confusion 🏆
Reading about pre&post 2015 classes + prototypes made me feel like I gained 40 IQ and a new philosophical outlook on how machines will take us over in the future. Thanks fun fun function
Dude, you're a trooper. Thanks for still doing a video even though you clearly didn't have the energy to
It's all helpful and all, but I can't imagine using it in real life sytuations. Could you show prototypes implementing in real code?
Sure. Please implement a duplex stream in node.
I think an easier approach would have been to show class extensions with prototypes instead of extensions of Objects. Basically prototypes is what you use in Ecmascript 5 when you want to extend a class (you can use it instead of the class name in ecma2015 instead also). Object.setPrototypeOf was interesting to see used on Objects. Haven't really considered that before. Great vid as always funfunfunction.
Fairly helpful especially the segment about constructors eloquentjavascript.net/06_object.html
I would go forward to use prototypes instead of usual classes (like in all other languages not necessarily in js). Imagine you are trying to build an online shop for pets (not sure if legal). You will probably make a initial object "animal" with price and sound. Then you will make dog object which will have a boolean property "hasFleas" and in the case of the video sound set to "woof". But nobody goes to the pet shop saying "One dog please!" so you will have to make objects with breeds. Each breed's prototype will be the "dog" object. Then you can add different characteristics to each breed (properties). So there it is! That's how I understood the concept. I could be somewhat wrong as well as right. Would be nice to see more explanations to see if I messed that up. Good luck! :D
github.com/googlecast/CastVideos-chrome/blob/master/CastVideos.js
Would this code sample with google copyright be a little bit helpful?
Your plant is growing fast :o
one not probably not obvious comment about THIS: so "console.log(this)" will always point on current object but "console.log(this.sound)" in case where it does not exist in current object will be found inside of parent object or in the prototype itself
Hey MPJ, I *love* your videos. OK, I followed ALL of this up until you redefined the talk function... the dog sound updated to the 'teapot' text... why didn't the prairieDog sound? If its following the prototype chain up, shouldn't it have seen and used the updated talk function, too?
It feels like every prototype tutorial online uses the same super basic example, that never really shows the usefulness or real life application of prototypes.
Your delegate analogy was great at the beginning but then it was just 15min of basically repeating the same thing.
I'd really love to see this expanded upon to really show, how and especially when you should use prototypes in real life to make your life easier.
+Man Kind well, this was the basics. ;) I repeat the same thing over and over in different ways because I've found that it's really hard to get how this works. But I agree with you that there needs to be some real-world examples of the prototype somewhere along the lines. Not sure if it's for this series though, as I intend this to be an overview of object creation in general, not a deep dive in prototypal inheritance.
Man Kind
Prototypes basically allows you to add attributes and methods to an object on the fly without the need to rebuild the object from scratch everytime like in a class object.
Like in a usual class object a cat would have all the properties of a mammalian feline. But with a prototype object you can give the cat bat wings cause why not?? :p
But then you'll still be wondering how this is useful. Well since in Javascript everything inherits from the Object and thus everything in Javascript is built with prototypes. You're now like yes I know this so how is this useful? :-)
It's useful cause you can tack on functionality to objects that never had any intention to have such a feature! You could make sound paint an image. You could make texts count things. You could make a cat bark.
Cause then you'd be questioning can't I already do these with classical inheritance?? Well no cause classical inheritances goes down like a tree while prototypes is like an agglutinative language. You can just pile stuff on top of it to do things without any worries what class or category it should belong to! 😁
It's a very cool concept and you could do some crazy things since theres no restrictions. It's why to prevent such freedoms Javascript have a strict token so programmers won't misbehave 😃
Flash Man that's very succinct! Thanks
For me, this is very clear. Thank you.
Thanks for making our mondays better =D. Can you please add a fiddle when you're explaining things to a real-world example. I do get the explanation but I can't find where does this fit in a real application.
And for those who want a proof that ES6 classes are actually prototypes, then consider the following:
class Square {
constructor(height, width) {
this.height = height;
this.width = width;
}
}
function Person(name) {
this.name = name;
}
console.log(typeof Square) //outputs "function"
console.log(typeof Square === typeof Person) // outputs "true"
Good job! Maybe you could make some episode about getters and setters in javascript? What they are, and what is the reason to use them?
I liked how you compared classes vs. prototypes :) nice video mate, keep rollin' :)
Thank you so much man, ive a so much better understanding of objects, prototype, bind and this! Wonderfully explained! : D :D
your the best and i wish you the best thank you
18:00 "setPrototypeOf is never used in real applications" What do you use instead? Object.create?
Great video, as always.
But I'm confused by what you did not say: prarieDog says 'WOOF!', even after replacing animal's talk property (and prarieDog's talk does not exist, so it should look into dog prototype for talk, not finding it there, it should look in animal's prototype; obviously I'm wrong somewhere)
So what I understand is that prototype is like a asking a project manager to do something that he can't do himself and he says ok, then passes it on to the person that has that skill in his team to get the work done.
+Damain Joseph yeah, that is good way of thinking about it. Others have used elected officials as another.
video begins at 5:00 for those who don't need convincing to use the prototype.
nice video but I'd go a bit deeper on best practices and quirks. for instance when a prototype object has a property that points to an object or array
I think of the prototype stack like css inheritance. If a style is not found for the class, then what about the div. If not the div, then what about the body. If not the body, then what about *.
The talk function towards the end should not be garbage collected because it could possibly be assigned dynamically later in the program ( I think) , right?
Thanks for video!
Good luck in Brasil :)
In short, prototype is a way of implementing inheritance between two objects, one being the base object and another being the one inheriting the properties of the base object. Do I make sense?
Loved the video. Don't forget your Mosquito repellent for your trip to Brazil.
+Brandon Bernal I has it
:D
very good vídeo
we are waiting you in Brazil
So helpful and your shirt is rad
MPJ can you please make a video discussing the newly proposed (stage 2) Decorators?! 😀
I like the how you explain things the simplest way :)
Also, you could now show how prototypes are used in real life
PS: greetings from Brasil :D
awesome man prototype is so clear for me now keep the good work
Are prototypes primarily a memory optimisation? Rather than defining push on every array instance, it is defined once on Array.prototype and every array points to Array.prototype.
this guy is awesome
hi, your episodes are really good.. javascript is really different language... there is more talk about progressive web apps.. in future can you make it some small about this term..
A prototpype of an object is an object willing to rent its properties and methods to that obejct to use.
I love your videos! One question about this one - why are you using keyword `let` to initiate objects? They are not being reassigned, right? Why not const in this case?
@mpj can you explain how "bind" is different from "apply". Also explanation for "call" and "super" would be great. Thanks.
Great video. Keep up the good work
Cool! See you on Friday at Braziljs! :)
To bring this all together, could you do a vid using prototypes to model the DOM in JS? The examples with traversing up the prototype chain for data makes sense, but the interaction of prototyped functions and instance data isnt.
Great vids. Thx!
5:07 Could? Should? Nice
I loved the part where you said... why don't you marry prototypes. :). Please mpj, i would like to know which softwares you use for your web series. I would like to start a video series soon and I'm looking for some tips.
see the behind the scenes episode
I think you are a Grammy award actor
It seems like prototypes would be heavier on your processor whereas object inheritance would be heavier on memory usage. Is there any significance with larger objects?
+BlueEagle there is only one kind of inheritance built into JavaScript and that is prototype inheritance. Any kind of inheritance will need to be built in top of prototype like inheritance, or have some kind of custom solution implemented. If you build something on top of the prototype model it will have extremely similar memory characteristics unless you make a mistake somewhere.
Thanks 🙏
Are you planning on doing more Haskell videos? I enjoyed seeing your experience of the language. :)
No
thanks alot!
Sugestion for next episode, must-have libraries for js devs, your fav libs or libs reviews.
there is no universal library worth recommending. Pick the right tool for the right job.
I know it isn't exactly the same, but his episode about tooling probably safely covers his opinion on this. (#31 "What editor do you use?")
Makes so much sense thank you! You said set protypeof isn't used in real applications what is then used?
+Brian Coates (Gamers 4 Life) I have no clue. I was so happy to find it for this episode, because it makes it a lot easier to explain the prototype, but I have clue when you'd use it in production code.
I think what I'm trying to say is how would you implement prototypes into code today if you don't use prototype of to create a relationship what do you use? Hope that makes more sense.
Prototypical inheritance is like you loosing your pen in a class, then you first ask your friends if they have an extra, if they don't, then you ask your 'non-friends', before you then ask your enemies. :)
Not quite.
It's like you losing your pen and you ask your friend (you have only one) if they have an extra. If they don't they ask _their_ friend (they have only one) if they have an extra. And if _they_ don't they ask _their_ friend (they have only one), and so on.
Until either you have your pen, or run out of friends of friends.
same thing i said
The distinctions are quite critical 1) relationships between classes should never mutate; you don't ask your non-friends or enemies. 2) it's easiest to think of the request being passed to a new actor rather than thinking that the first actor changes their request and 3) prototypal inheritance as it's implemented in ECMAScript does not support multiple inheritance so it's never possible to ask more than one friend.
A better example might be passing a note to the person behind you, asking for a pen, then that person passes the note to the person behind them. The relationship between person A and person B is the same as the relationship between B and C (but different from the relationship between A and C) and the note can only be with one person at a time.
+Crispen Smith I see.
I guess it's more accurate if you flip that analogy upside-down. You are the "pen-holder" in your class, (the prototype). Whenever any of your friends need to write something down they have to ask you for the pen. Or, taken even further: You can't give them the pen; they have to tell you what to write and where to write it, and you write for them.
"Just like giving needles to drug addicts." lol
thanks for doing this!
Thank you for the tutorial, i really like it but
i think cats and dogs will not be practical way to learn prototypes
lets build something practical that uses these concepts.
mice*
How about Dragons and Knights!
Best videos!! thank you!!
Love your stuff I'm a great fan.
At 2:13 that symbol you make actually means "f off" over here in England, but from reading the comments here I'll imagine you do mean that to some people!
+Daniel Gent multiculturalism is hard :)
Hello MPJ, you have made some arguments against inheritance in favor of composition. I would like to know if those same arguments apply to prototyping as well. Thank you for your videos, they are very helpful! :)
Great vid!
Question: Is there a way to console.log prototypes of objects to visualize the prototype chain?
+Algo4Life it you console.log the object you can just expand the prototype.
I suppose that before you set the cat to have the prototype of animal it already had a prototype which was the global erhm...prototype? And as you pointed out a few seconds before the global prototype doesn't have a talk function. So if you then call the cat.poop() function neither the cat, the animal nor the global prototype will have it. Correct?
Actually, let me take that back. Its prototype is undefined of course. But the __proto__ is {} which means it's an object. Aaah, very confusing. :)
Have you tried Typescript or Coffeescript? Apparently they are better to code than vanilla Javascript itself (I haven't tried it yet)
@10:19 You assign object 'cat' the prototype of another object 'animal'. If only functions have prototypes, I don't understand how it's possible to assign one object, the prototype of another object?
Functions don't only have prototypes, prototypes are a property of objects in general, and functions are a type of object. Also you reassign the prototype of an object just like you can reassign any variable, but with object functions like Object.apply(), or Object.create(). this just adds or reassigns the scope that object has access too. So when MPJ adds to/reassigns an object's prototype-with setPrototypeOf()-, when before he called talk() it threw an error now it will have access to a scope with a talk method.
Disclaimer I am self taught but that should be accurate information if I explained myself well enough.
Thanks Colin. I was getting confused between __proto__ and .prototype. Since you mentioned you are self taught, I am as well, and I'm wondering if everyone else might be as well. It doesn't seem like javascript is actually taught in schools, at least never mentioned if it is. If this is the case, it probably would save people a lot of time because javascript is not what it appears to be, when you are first exposed to it, and it takes a while.. months, to figure that out on your own. Then depression sets in, having to relearn something you were already comfortable with.
It can be depressing but if you focus on project creation and let your learning of a subject be based on if it is needed to finish said project, you will have more tangible success. You have probably made a very long journey just make sure you are creating things even if it is a calculator.
While I am 100% comfortable with classes in Java, they seem to just add more stuff to the pile in JS which is not really needed. As you say, one still has to understand the prototype. So what is the purpose then? To trick certain programmers to think that they know JS?
Offering a different route to the same goal I feel, giving programmers the option to choose a programming style that suits them.
the way they keep adding stuff to js, it could just become one big gigantic mess, the class functionality is totally unnecessary.
I agree, though javascript seems to have always been a bit of a mess. A beautiful mess, but still a mess.
Great video! When creating objects, I love to use "__proto__" property, e.g. "dog = {sound: 'woof', __proto__: animal}" because it makes the code shorter. Isn't it good or bad? What's your opinion?
From a purely semantic standpoint I really like it because it's really clean and more in line with how protoypes actually are, but unfortunately, like setProtoypeOf, it has horrible performance characteristics isn't really advisable in actual apps. See: developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/proto
I know that changing object prototype (by calling Object.prototype.setPrototypeOf or assigning Object.prototype.__proto__) is expensive, and what Object.prototype.__proto__ setter does is calling Object.prototype.setPrototypeOf.
But I still think "__proto__" in object literal (object initilization) is not "Object.prototype.__proto__" (object assignment).
To demonstrate my assumption, I create a property setter for Object.prototype: gist.github.com/KSXGitHub/a740a7366533306ec65fb9c9ce1a81a2
Moreover, I personally wouldn't care much about performance when code in JavaScript. If I concern about performance, I choose C++, or Python at least.
thank's yr fantastic
Sorry, my native language is not English, but when I was first learn prototype, I was confused with a word protoss( A race in Starcraft, which is made by a company call Blizzard). My gut tell me that it maybe has some realtionship with it...One day, Ah ha!
If you have played that, you will understand my example:
let's say you choose terrain for example.
ok, you build a factory to generate marines. this factory can be treat as a Object that has marine prototype. and this Object can generate marines. And each marine initilize with a attack and defence properties, and equeals to 1. This is very important for me to understand prototype, Why? Becasue, the properties which the marine has will be upgrade in the future. that's why I using this case for example. During the game, you might want to upgrade the amys attack proterties. When the research complete. All the marines of you amy, will be upgraded, not only for the marines that hasn't created, but also for the marines that has created.
if we don't set the properties on prototype, this will only effected on the marines that will create in the futures, not for created marines. So you will think this is not fair. you should research the attack first, then, create marines...if you do want game to be like this. you just need upgrade the factory marine prototype.
This is the case always in my mind....haha...My life for Aiur!
thanks !, and about ECMS6 class , it's same ?!
Great video, but to be honest, Fuck prototypes, at least in ES5/6. They are way slower, and heavier than `new`. Hell, even the actual implementation of Object.create uses `new`. I just spent last week trying to get them to stop giving me an entire Jungle, that has a banana tree, that has a banana, when I use Gorilla.eat(banana);
To those interested I found 2 strategies for Object creation outside Object.create.
1.) Use a constructor function ( var/let Fn = function()), then attach a new prototype, passed as an param, or bound with (.bind(Proto)), and set the older prototype to Fn.prototype.parent, but this still comes with all the baggage of prototypes.
2.) Use a combo of new and Constructor to return a Factory which allows you to have multiple constructors with bindable protos if you wish through bind or call or apply or whatever.
This allows us to separate construction and initialization and the initialization can be deferred to multiple constructors. This also uses closure to instantiate the Object.
var Proto =
{
hammer: function(everything, isANail)
{
var Hammer = this;
Hammer.bang = 'bong';
return Hammer
},
pliers: function()
{
var Pliers = this;
Plier.pull = 'fingernails'
return Pliers
}
}
Objects.produce = function buildFactoryFromProto(proto, subclass)
{
var Product = new proto();
if(subclass && typeof(subclass) === 'string' && Product[subclass])
{
return (Product[subclass]); // RETURNS CLOSURE INSTANCE
}
return (Product); // RETURNS CLOSURE INSTANCE
}
var tools = Objects.construct(Proto); // Factory
var pliers = Objects.produce(Proto, 'pliers'); // Factory With Constructor Fn Returned
var hammerhead = Objects.produce(Proto)['hammer'](42, 'Nails'); // Factory made, Returning A Constructor Fn we call
var hammertime = tools['hammer']('Ohohohoh', 'Stop'); // Tools Factory Returns Hammer Constructor Fn we call
would you tell me what's a difference between .prototype and .isPrototypeOf?
They are pretty different things, why would you think the are the same at all?
I love you man
good sunday night.
Is it better to use Object.setPrototypeOf instead of Object.Create?
+MrTrickydisco no. I'm just using .setPrototypeOf in order to explain only one thing at a time.
Thanks for clarifying. Would you use .setPrototypeOf in production? Looking for examples that you'd actually in production. Love the vids btw. I've learnt loads since finding you a few months ago. When are you coming to the UK to speak/tour?
share your prompt config
You'll do fine with your talk! Don't worry~ = )
commented to thank you!!
Great video as usual! When you're talking about chaining I think you missed to use prarieDog.talk() to show how it's accessing the prototype of the prototype.
it's looks like bind function
Were you fixing a printer?
Thanks for the video :) So the only difference between class inheritance found in a language like Java and prototype inheritance is that in prototype inheritance you always inherit from object(s) itself, but everything else is the same?
That is the core difference, yes, but "everything else" doesn't really mean anything in this context (or many contexts at all) so I cannot say. :)
This might be a bit too blunt but it is a good way to keep them separated in your mind. Javascript: the good parts has a good explanation about the difference between class-based and prototype-based languages and that's the core of it.
Can you explain promises on JS sometime? I'd like to see that. If you have, sorry just haven't seen it.
+wuz352 there is a fff video on promises ;) search is your friend. ;)
Aaah, pre-coffee, MPJ. I normally would've looked. Thx, man!
Awesome!! More more more!! :D :D
That's a cool tshirt! Is there a place I can buy one?
+seriypshick sorry, it's an internal Spotify shirt. :(
I think your camera more focus on your plant :)
+muhammad faisal rahman yeah, sorry. The production of this video was rushed. :(
But it still great videos. Hope you make another video about queue :)
So it's kind of like a kid standing in front of his parent?
The kid will answer every question he can but if he can't answer he'll look over his shoulder and hope that his mum can answer for him?
Could it be thought of as a proxy object ?
It's more the other way around. A proxy is generally something that is accessed _first_, sitting _in front_ of the real thing you want to do. You call the proxy, and the proxy calls the object.
A prototype sits _behind_. You call the object, the object can't find what you're looking for, so it calls its prototype. Like a safety net if a property access falls through.
+Thomas Giles great answer, Thomas!
Think about it in a way an event propagation works - it worked for me to understand it that way.
When you have nested elements the event will bubble up until it finds that particular definition on an element. Similar with prototype, the search will "bubble up" in the prototype chain until a method called is(not) found.
I thought I was following you until I got to "until a method called is(not) found". Not found ? could you clarify ?
Yes, I meant "is found or is not found". Sorry for the confusion.