getify
"this & object prototypes": editorial review (about chapter 6)
Per Kyle's request, I'm posting what I find to be the serious issues with chapter 6 as they now stand; of course I'm open to being persuaded that I may have missed something. This is mostly from an Amazon review. I'll do my best to translate to second person, but forgive me if a few third person references to you survive.
The tl;dr is that this chapter does not adequately discuss how constructor functions are used idiomatically, and not honestly compared to OLOO. Specifically, there are many, many situations where OLOO is far worse than well designed constructor functions, and an unsuspecting new developer reading this book may take away some simply awful habits.
Chapter 5 was good. You explain how prototype chains work, and how to create an object from a prototype: Object.create. From here I assumed you would show the limitations of Object.create: that to create a "family" (I'm avoiding using the word class for obvious reasons) of objects you'll need to repetitively code up factory functions of some sort that create the object using Object.create, then set the relevant properties, then return the object. Something like this (contrived of course):
function createPerson(name, birthday){
var result = Object.create(personPrototype);
result.name = name;
result.birthday = birthday;
return result;
}
Which would then be a perfect time to explain why constructor invocation exists, and how it very cleanly solves this very common problem, albeit with some syntactic baggage unfortunately borrowed from Java.
Nope. The chapter ends, and into 6.
Chapter 6 would have been a tremendous opportunity to thoroughly explain how OO development in JavaScript is typically done--constructor functions--with alternatives that might occasionally be appropriate, namely your OLOO. Instead it seemed to devolve into a tirade about how standard JavaScript idioms aren't to the your liking, and why developers should instead use OLOO, which actively hampers many common use cases (use cases you do not bring up). Any non-expert JS developer who reads this chapter may pick up some bad advice which is very easy to misuse in a professional environment.
Many of your examples seemed like gross misrepresentations and sleights of hand picked to make (typical) prototypal inheritance (constructor functions with chained prototypes) look unnecessarily bad. On page 132 you present the following, as part of the "traditional class design pattern"
LoginController.prototype.failure = function(err){
//super call
Controller.prototype.failure.call(this, "Login invalid: " + err);
}
Overriding a base method just to lock in a string prefix? Fine; book examples can be contrived. The problem is that the alternative you present with his OOLA is this
AuthController.rejected = function(err){
this.failure("Auth Failed: " + err);
}
You just made a brand new method with a new name that calls this.failure, with this.failure resolving up to the prototype (just like before). The reader may be left wondering why this possibility was never brought up for the "traditional" way
LoginController.prototype.rejected = function(err){
this.failure("Login invalid: " + err);
}
or a new reader may be left with the impression that this way does not exist in the traditional idiom.
The rest of your comparison seemed to involve similar sleights of hand; it almost seemed apples-to-oranges. On page 134, when implementing your OOLA pattern you completely cut the inheritance hierarchy up to appear simpler. Couldn't this have been done with the "traditional" pattern? You also don't point out that the errors array had to be re-initialized, and that any developer following this pattern would have to also re-initialize every. single. other. property a base object may have (yours had only had the one, and so hid this complexity). And of course you fail to consider the difficulty this code would have if you ever needed to create a second, or third of these objects. These are all things that constructor functions handle seamlessly for you.
Why not discuss these issues so the reader has a fuller picture? Was there a word limit I'm unaware of?
Finally, is your mental model for the traditional way really honest? Surely this suffices for the vast majority of developers
obj.foo();
- box is shown of obj, listing obj's own properties
- foo is not there, arrow takes you up to obj's prototype
- check there
- repeat step 2 until found, or prototype chain exhausted.
While—if they're a senior dev—also knowing (in the back of their heads) that there are also constructor properties at each level pointing to the relevant constructor function.
You did explain how prototype chains work earlier in the book—and well. Why not tie it together with a more thorough exploration of constructor functions?
Note, I took the time to write all this up, albeit originally excessively angrily on Amazon, because many young developers learn their trade from books like this. Years ago Crockford's text was extremely influential to me—in a bad way. I accepted his opinions as fact, and frankly wound up looking foolish. I don't know if Crockford's reasons for (ostensibly at least) hating constructor functions are the same as yours, but it can be a (somewhat) harmful thing to put out there when presented like this.
I very much appreciate that you've taken the extra trouble to engage in a conversation here so that I can pull out actionable feedback to find ways to improve the content. That's the whole reason I wrote all these books in the open -- to collaborate in making it better with others.
Rather than just knee-jerk react, I want to take some time to compose responses to your feedback, so I will come back here and do so over the next couple of days.
But I want to make one thing clear: my goal is not to convince you that your review/opinions are "wrong" or need to be "changed". You're entitled to them, and I respect that your experiences seem to differ greatly from mine with how JS is appropriately applied in the real world. My goal is explain some of the things that motivate my opinions, which I had hoped the book would get across, but which from your comments may not have adequately done so. :)
It's fine, really. Honestly I'm just interested in hearing the thought process behind this chapter.
@getify Was wandering through this thread and would be interested to hear the follow-up, if there's any interest in answering further.
I don't have any comment on this thread in particular, but I can definitely say I have plans to cover classes vs delegation a bit differently in the refresh of second edition.