Because it's a function that doesn't need to be called. new
is not that different from a regular function call in Javascript.
A constructor can do more than simply set fields. For instance, if it validates incoming data, then you will cause a validation
error when you were simply trying to set inheritance chain.
And you don't need Object.create
, this is sufficient:
function objectCreate( proto ) {
function T(){}
T.prototype = proto;
return new T();
}
The brace at the end of the line is the ancient K&R C standard, from Brian Kernighan and Dennis Ritchie's book The C Programming Language, which they published in 1978 after co-inventing the UNIX operating system and the C programming language (C was mostly designed by Ritchie, based on B, which another Bell employee Ken Thompson had adapted from the older BCPL programming language), at AT&T.
There used to be flame wars about "the one true brace style."
So Ritchie created the C language, and Kernighan wrote the first tutorial, when computer displays only showed a few lines of text. In fact, UNICS (later UNIX) development started on a DEC PDP-7, which used a typewriter, printer and paper tape for a user interface. UNIX and C were finished on the PDP-11, with 24-line text terminals. So vertical space was indeed at a premium. We all have slightly better displays and higher resolution printers today, right? I mean, I don't know about you, but I have three 24" 1080p displays in front of me right now. :-)
Also, so much of that little book The C Programming Language is code samples that putting the braces at the ends of the lines instead of on their own lines allegedly saved an appreciable amount of money on printing.
What is truly important is consistency throughout a project, or at least within a given source code file.
There are also scientific studies showing that the brace on its own line (indented to the same level as the code, in fact) improves code comprehension despite what people think they think of the aesthetics. It makes it very clear to the reader, visually and instinctively, which code runs in which context.
if( true )
{
// do some stuff
}
C# has always supported evaluating a single command after a branching expression, by the way. In fact, that's the only thing it does, even now. Putting code in braces after a branching expression just makes that one command a goto (the compiler creates scope using jmp instructions). C++, Java, C# and JavaScript are all more or less based on C, with the same underlying parsing rules, for the most part. So in that sense, C# is not "based on Java."
Summing up, this is a bit of a religious/flame-war issue. But there are studies making it pretty clear that arranging code in blocks improves human comprehension. The compiler couldn't care less. But this is also related to the reason why I never put a line of code after a branch without braces--it's just too easy for me or another programmer to slap another line of code in there later and slip on the fact that it will not execute in the same context with the line right before or after it.
EDIT: Just go look at the Apple goto fail
bug for a perfect example of this exact issue, which had very serious real world consequences.
if( true )
doSomething();
becomes...
if( true )
doSomething();
doSomethingElse();
In this case, doSomethingElse()
executes every time, regardless of the outcome of the test, but because it is indented to the same level as the doSomething()
statement, it's easy to miss. This isn't really arguable; studies back this up. This is a big source of bugs introduced into source code during maintenance.
Still, I'll admit that JavaScript closure syntax looks a little silly with braces on their own lines...aesthetically. :-)
Best Answer
Look up Object.create for an alternative to function constructors which I actually find very useful since they give you encapsulated instance vars via closure.
I'm not sure how long it's been available but I've been using <object>.constructor.prototype for some time now.
But really, JS was written in 10 days. It's been evolving from that rush job ever since. I'm not even sure they had prototype on function constructors when it was first released. Netscape's top brass wanted it to look like Java. Brendan Eich wanted it to work like Scheme (and decided he was making it look like C rather than Java, by which I assume he's stating he wasn't a huge fan even back then).
Also, Good Parts is a decent read but it's not the ultimate authority and Crockford has some really weird hang-ups about the language. Function constructors in particular which he's claimed are bad because you might forget to use new keyword and screw up. Well, you might forget to wear your pants in the morning too but you tend to notice pretty quick.
Took me a bit to find this but if you really want to know how it came about, it's best to go to the horse's mouth:
https://brendaneich.com/2008/04/popularity/