Yes, I know...but look at how much nicer that is to type than his first example...
Pretty good, straight forward write up though!
I will use it. Because syntactic sugar in this case does save some work. But I'm very conscious the code has swapped superficial clarity for deep lies.
I suspect Stack Overflow will overflow with even more 'javascript OO is broken' questions and the MDN article won't make more than a dent on clearing up that (deliberate) confusion.
I agree with Crockford on this.
I am very grateful to Crockford for the "Good Parts" book and JS5 - I like that lean approach.
`class` just picks one and pretends the rest never existed.
Lua is another well know language that has prototype-based inheritance.
Instead, this sets the stage for lots of OOPish JS which feels very different from a lot of existing code out there, and will result in awkward shims to interface the different paradigms.
We already see such ugliness in C++.
That's a bit strong. Most languages come with a standard set of data structures, but that doesn't mean they make it impossible to implement other data structures if it suits you (e.g. few languages include binary trees as a standard data type, but that doesn't mean you can't use them).
C includes standard string algorithms, but that doesn't mean you can't write your own — you can even create your own string type if C strings are problematic for some reason.
Many things in many languages are there to offer a reasonable default that is generally useful. This seems along those lines to me.
That has never been the case with most standards. No see why start now. If it's a standard, it should just be present to all engines, and (but not necessarily) the most popular option.
Nothing about it being a standard necessitates it should be "the only option".
>Instead, this sets the stage for lots of OOPish JS which feels very different from a lot of existing code out there
Quite the opposite. This sets the stage for finally having code that looks THE FUCKING SAME as other code.
Instead of 200 ad-hoc implementations of the same exact OOP pattern -- which is what we have now.
Are Python classes broken as well?
Besides, most people used prototype based inheritance in this exact manner, so it's good to codify and give a concrete implementation, instead of 200 ad-hoc remakes of the same thing.
Third, people still get all the prototypal flexibility anyway if they want it.
I think that's a good argument for including the syntax, though it raises me from 'anti' to 'ambivalent'. But yeah, figuring out random coder's favourite OOP implementation style is an annoyance. Here Crockford seems to be a bit part of the problem: he seems to recommend a whole new approach every couple of years. His recommendations to never use 'new' (and now, don't use 'this') make it a pain to use other people's objects.
I wonder if a better consensus might be the best of all worlds.
you make that sound like a negative. If you find a 'better' way, why not use it?
var foo = Object.create(bar);
var foo = new Bar();
var foo = Bar();
var foo = Bar.create();
Thus I have no problem with him finding better ways, but his influence and his way of presenting things as the one best solution causes issues, in my experience.
Do you feel the same way about Python's use of the word 'class'? Because Python also uses prototypical inheritance under-the-hood. The abstraction is clean enough that most people don't know the difference, but it still really is "just" prototypes down there if you peel back the layers.
That said, Python is a hybrid under the hood. It has become more prototypal over time, but still enforces the distinctions between classes and instances.
I personally think that the opportunity to fundamentally open Python to a better object model was missed when Metaclasses were added. I like Metaclasses in Python, I think they need to be there, and help all kinds of tasks. But it might have been better still to support full prototypal inheritance at that point.
The complaint I'm making is definitely true of Python though, because it dresses its objects in the outfit of classes and instances, few programmers end up understanding the underlying model and how it can be used to improve their code. And, because of that, it is unwise to use those techniques in code that will be written and maintained by a team. I tend to get nervous of code that uses custom Metaclasses, for example, because of the burden of education is imposes on a project.
I'd prefer a situation where Prototypal inheritance was actually taught as the Javascript approach. But perhaps that is utopian and naive.
Is Crockford's dislike still based on this: http://www.crockford.com/javascript/inheritance.html ?
Because I don't quite buy into that line of thinking. I'm really looking forward to webassembly…
Beyond that I'd argue that classes give you more guarantees about how an object will behave at the expense of flexibility, although they give you escape hatches if you like. The reduced flexibility is really nice because you can define safe subsets of the language in which tools that analyze and refactor code are possible, even across files if you're using the module system. Moving the language in a direction where consistent universal tooling is possible to write is something that I love about classes, and is often overlooked in discussions about it. I don't care that classes are just a simplified subset feature of what's possible using prototypes, it covers the common case well enough and makes it possible to write really nice code completetion and refactoring tools that don't randomly break. That's worth all the extra magic in my opinion.
function Animal() {}
function Cat() {}
Cat.prototype = Object.create(Animal.prototype);
(function(fields) { fields.forEach(function(field) { Cat.prototype[field] = function() { // Some nonsense }; }); })(['what', 'the', 'hell']);
It's impossible to statically infer what methods are being declared in ES5 code in general. You can pick up on some common assignment patterns, but not all the weird stuff people do. Just check out the top 10 NPM modules and I guarantee you'll find some odd assignment patterns. I can remember that the "colors" module did meta stuff when I last checked. You can't just easily run the code to find out what the module is exporting either, because of potential side effects from IO. You can wrap Node's core IO modules, but that solution is specific to Node, and still won't cover every possible case. In short, it's a huge pain to write tools to pull information out of Javascript code in general, and that hurts the tooling ecosystem around Javascript.
With the class pattern you at least have some staticly inferable information you're sure you can pull out of the class, and weird stuff is discouraged. I know in some ways that this is a weak argument, because of the new square bracket assignment, and the fact that anyone can muck with the prototype of the class after it's created. Even still, for the simple OLOO case it does encourage people to write code that has method names that can easily be staticly inferred, and that's a good thing for JS tooling possibilities.
I really just want omnicompletion that doesn't randomly break on me! The OLOO pattern is one that's incredibly common in JS