this & Object Prototypes - Chapter 4: Polymorphism definition

[agustinrodriguez]

I think that the following definition is confused

Another key concept with classes is "polymorphism", which describes the idea that a general behavior from a parent class can be overridden in a child class to give it more specifics. In fact, relative polymorphism lets us reference the base behavior from the overridden behavior.

It looks like the idea of inheritance and method overriding. As I understand, polymorphism is the capability of two or more objects to respond the same messages (aka, same methods). It's a much more generical definition, but keeping in mind that is a key concept, worth clarify.

I think your point here is that a Base Class and a Child Class can have a same name method, but with a different implementation, which is closer to polymorphism. Anyway, it seems not very clear.

This issue doesn't aim to change your original definition, but I really want to know your opinion about this.

Maybe it could be related with this issue

[ytsejammer]

Hello Agustin,

I agree with you that the paragraph could be more specific. I believe the concept of polymorphism is more general and can encompass method overloading ('parametric polymorphism'; same name, multiple behaviors with different method signatures), overriding ('subtyping'; implementation varies depending on the type dispatching the method invocation.)

That being said, I think that referring to the behavior just as 'polymorphism' is a little too broad and should be refined in the interest of clarity.

[sminutoli]

Indeed, the whole idea of ducktyping relies on polymorphism, if we want to bring some case far away of inheritance. Or you can borrow props via Object.assign and you're polymorphic (you behave as a) the source object in a sense. I think that the topic could be mentioned in others sections, to grasp the wide-range that polymorphism covers on OOP.

[getify]

I don't see the problem. This book is not intended to be an authoritative treatise on general non-JS OOP. It's designed to explain the parts of those concepts that are necessary to ferret out what JS doing. There's plenty of other texts that explain OOP (class-oriented theory) in much more detail than mine, and that's on purpose.

[zonzujiro]

@agustinrodriguez I totally agree about relations of our issues.

About polymorphism, inheritance and overloading - I think mashing up of this concepts is a bad idea. Especially in the book about programming. This is a basic stuff and very important to understand how they work and for what purpose they exist. Of course, some things in JS are different from other languages. But the peculiarity of JS can't be a justification of distorting in the understanding of the basics concepts.

But still, it's a good book about JS.

Also, I want to pay attention to another discrepancy, which I was told earlier in my issue - @getify in Ch. 4 tells that class inheritance always use copying of data, which isn't right. I described reasons why I'm thinking so in my issue. I'm saying this, because, in Chapter 5, which I'm reading now, author several times focuses attention on that fact.

[agustinrodriguez]

@getify What I want to say is polymorphism is far away of "Class Pattern". You treat that concept quite specific.

I mean, if a person who starting with JS and Programming (which I think these series of books are pretty cool for that) reads this and talks with another person of polymorphism, doesn't transmit its basic essence. And that essence applies to JS better than a "method overriding" definition. As @sminutoli said the idea of duck typing applies a little better to polymorphism itself.

"if it looks like a duck, and it quacks like a duck, it must be a duck".

And it's polymorphic with a duck.

It isn't a problem, and it isn't necessary much detail. Just it would be nice if you touch OOP concepts, put up the essence of them.

[getify]

I appreciate the feedback, but I am not persuaded that my text needs to change. I'm not writing a book to precisely teach you about classes... in fact, I'm trying to persuade you NOT to use classes in JS.

I used took some artistic license and used some informalities in the discussion to keep from having to write hundreds of more pages about classes, but I'm comfortable that these informalities do not actually detract from the message I'm giving, which is that classes are awkward and troublesome in JS.

[sminutoli]

Seems like we're loosing a great opportunity to learn that strong concepts in OOP as polymorphism has nothing to do with classes. In fact, clarifying it would lead you to say...

you want to share functionality? you dont need at all classes, you've rough linking to prototypes for free

you want polymorphism? dont let the class boys confuse you, its only about a contract between objects, the famous program to an interface not to an implementation.

you want privacy, unaccesible members? you've got closures

I love the YDKJS series, and all your effort pushing the OOP away from "classical OOP", embracing the Self nature of the language.