Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Javascript Constructors and Prototypes

tobyho.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Javascript Constructors and Prototypes

#21

Post by nhebb »

pests wrote: post #5
gregorkas wrote: post #2

I wanted to read this because I believe it's a great article, but the fact that he doesn't use semicolons pretty much turned me off. While I was looking at the JavaScript code my brain almost exploded.

Did you see the article he linked about why he doesn't use them? http://mislav.uniqpath.com/2010/05/semicolons/ Not reading an article because of that would be like not reading other code because it uses 2 spaces for tabs instead of 4. Makes no difference to the language, only to you.

I defer to Brendan Eich on the matter:

https://brendaneich.com/2012/04/the-infernal-semicolon/

Re: Javascript Constructors and Prototypes

#22

Post by marrs »

mradmin wrote: post #15
marrs wrote: post #11

Earlier quoted context omitted.

Why does it seem hipster to use a language feature? Is it hipster to use null coalesce as well? The article linked above explains the reasons to omit semi-colons very well. I would personally prefer if JS forced you to terminate all statements with a semi-colon to avoid any ambiguity, but there you go. Speaking of ambiguity caused by whitespace, Coffeescript is a 1st degree offender for this. All you have to do is in…

It's hipster because it goes against the accepted standard way of writing Javascript. See https://news.ycombinator.com/item?id=1547647&utm_source=twit...

My interpretation of "hipster" is being different because you think it's cool to be different. Being different because you think it's a better approach is called "making progress", either because you'll be proven right or proven wrong.

I've thought about the de-facto standard way a lot and I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse.

The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done.

Re: Javascript Constructors and Prototypes

#23

Post by derefr »

tlrobinson wrote: post #16
marrs wrote: post #11

Earlier quoted context omitted.

Why does it seem hipster to use a language feature? Is it hipster to use null coalesce as well? The article linked above explains the reasons to omit semi-colons very well. I would personally prefer if JS forced you to terminate all statements with a semi-colon to avoid any ambiguity, but there you go. Speaking of ambiguity caused by whitespace, Coffeescript is a 1st degree offender for this. All you have to do is in…

CoffeeScript certainly has its syntax quirks, but after some forced time using it I've found I can't go back to happily writing plain old JavaScript. The first week or two you'll regularly need to peek at the compiled source to be sure it's doing what you want, but you'll quickly get a feel for it. Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include th…

Oddly,

> Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include the parens and you should be ok.

this is exactly the parallel I was going to make to the discussion we're currently having here. People who want semicolons on every line, even when they don't matter, are the same people who want to parenthesize every infix operation, even when the natural precedence the expression has without parentheses is already correct. I'm not sure I understand it in either case--are you afraid that someone might edit the code without understanding the "implicit defaults" of the language's syntax? Why are you letting that person near your codebase?

Re: Javascript Constructors and Prototypes

#25

Post by marrs »

tlrobinson wrote: post #16
marrs wrote: post #11

Earlier quoted context omitted.

Why does it seem hipster to use a language feature? Is it hipster to use null coalesce as well? The article linked above explains the reasons to omit semi-colons very well. I would personally prefer if JS forced you to terminate all statements with a semi-colon to avoid any ambiguity, but there you go. Speaking of ambiguity caused by whitespace, Coffeescript is a 1st degree offender for this. All you have to do is in…

CoffeeScript certainly has its syntax quirks, but after some forced time using it I've found I can't go back to happily writing plain old JavaScript. The first week or two you'll regularly need to peek at the compiled source to be sure it's doing what you want, but you'll quickly get a feel for it. Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include th…

But it's the same as the problem with ASI. By making the parens optional you are inviting ambiguity and mistakes.

Re: Javascript Constructors and Prototypes

#26

Post by martin-adams »

wrboyce wrote: post #8
pests wrote: post #5

Earlier quoted context omitted.

Did you see the article he linked about why he doesn't use them? http://mislav.uniqpath.com/2010/05/semicolons/ Not reading an article because of that would be like not reading other code because it uses 2 spaces for tabs instead of 4. Makes no difference to the language, only to you.

The article (justifying not using semicolons) seems like a rant with not real aim, beside "I am right, semicolons are wrong - and I have all these half-baked ideas to back me up". The author was actually annoying me by the time I reached "It's good coding style". One example: > My advice on JSLint: don’t use it. Why would you use it? If you believed that it helps you have less bugs in your code, here’s a newsflash; o…

Giving advice to not use JSLint without a real alternative is very naive in my opinion. When I was working with a team of developers with some novice JS developers, JSLint was a godsend to pick up simple, avoidable bugs while enforcing some sanity with regards to code style.

Re: Javascript Constructors and Prototypes

#27

Post by GeneralMayhem »

This article does two things that are very dangerous, and never mentions the reasons why they're dangerous.

* Messing with Function's prototype is very strongly frowned upon. It's tantamount to setting global variables. At the very least, give that definition an if (!Function.new) guard to prevent redefining another implementation that another script (or the browser!) has already given.

* Adding methods in the constructor is awful even if you're not using inheritance, because it burns memory like crazy. If you define sayHi on Person.prototype, then every Person gets a reference to the same sayHi method. If you define this.sayHi in the constructor, then each Person you create gets its own copy of the function, making every Person heavier in memory. Not a big deal for a simple console.log, but if you have more complicated objects with a few dozen methods that you're using a bunch of you can really make things chug.

Re: Javascript Constructors and Prototypes

#28

Post by alexdf »

>>Cat.prototype = new Mammal()

This is only useful if Mamaml has only methods and no properties which does not happen that often.

>> Cat.prototype.constructor = Cat

I never saw a practical usage of this one :-)

I think these days the standard way of doing inheritance should be -> MyClass.prototype = Object.create(baseClass.prototype)

Re: Javascript Constructors and Prototypes

#30

Post by lmm »

derefr wrote: post #23
tlrobinson wrote: post #16

Earlier quoted context omitted.

CoffeeScript certainly has its syntax quirks, but after some forced time using it I've found I can't go back to happily writing plain old JavaScript. The first week or two you'll regularly need to peek at the compiled source to be sure it's doing what you want, but you'll quickly get a feel for it. Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include th…

Oddly, > Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include the parens and you should be ok. this is exactly the parallel I was going to make to the discussion we're currently having here. People who want semicolons on every line, even when they don't matter, are the same people who want to parenthesize every infix operation, even when the natural pre…

Some programmers are good at remembering large numbers of arbitrary rules. Others aren't, and I've worked with good and bad programmers of both kinds.

So yes, I'm worried that a colleague might read the code and not know what the precedence is, and they will have to waste their time looking it up (thankfully some IDEs now have an command to add parentheses quickly, but it's still a distraction from their actual task).

Pretty much all languages have some features that are more confusing than helpful, and good codebases avoid using those features (whether via formal policy or not). IMO most precedence rules fall into that category; it would be better if e.g. "a && b || c" were a syntax error until bracketed properly.

Post reply on HN