3 ms·

`this` is not a code smell, but trying to do variable hiding/encapsulation of attributes through closures leads to grotty code. Use the leading underscore conve

`this` is not a code smell, but trying to do variable hiding/encapsulation of attributes through closures leads to grotty code. Use the leading underscore convention. It's worked in Python for years. The article author will also be a lot happier when he realizes that Javascript might look like Java but it really wants to be a lisp.

silentbicycle 16y ago
To me, Javascript seems headed in the direction of Self, not Lisp. Not a bad place to end up, by any means, but why do people think Javascript is trying to be Lisp in particular? (I know Eich was influenced by Lisp, but so were ML and Smalltalk.) Sometimes I wonder if people just mean, "Wow, Javascript is actually a really expressive, dynamic language, once you get past all the idiosyncratic DOM stuff", but don't know enough other non-ALGOL languages to see that expressiveness isn't just a Lisp thing. Because hey, it doesn't have s-expressions, macros/static metaprogramming, an explicit compile-time phase at all, etc. It has much more in common with Lua or Self than Lisp. It could have been a really awesome language if the browser wars hadn't stunted its growth.
- grayrest 16y ago
  > why do people think Javascript is trying to be Lisp in particular? The reason I said lisp is because Brendan more or less always mentions he wanted to implement a scheme interpreter but Netscape marketing insisted that it look like Java. As for more closely resembling Self/Lua, I'd largely agree if for nothing other than the obvious object system similarities. On the other hand, I think the idiosyncrasies of javascript like `this` and call/apply, the enforced n-arity of functions, and a lot of the 'convert it to a string' fallbacks (think lisp 1) were attempts at fitting lisp concepts onto the self-like object system. Of course, I have no basis for this so I'm probably wrong, but it makes me feel better when I have to explain them. I will note that JS is moving into limited metaprogramming with the harmony proxies proposal. I also consider destructuring (another harmony proposal) to be a more functional concept than self/lua, but I actually don't know where that started.
eastgate 16y ago
I don't think we should refight the question of encapsulation here. Some people think encapsulation-by-convention is adequate, others don't. I'm also positing Crockford-style modules.(Since it's pretty clear from the context that I'm following Crockford, you might assume that I know about the Javascript/LISP connection.) The question remains: is repeated use of "this" this.Mill(); this.Drill(); this.Fill(); simply semantic vinegar, or does it suggest that the object is not doing its job -- or that we need a new object?
- grayrest 16y ago
  The problem is that you're applying C++ sensibilities to a prototype OO language. `this` doesn't refer to the current class, but to the current object. There are no classes and no methods. Functions don't even really belong to the object they're written in. You can easily rebind (using call/apply) a function to a different object so that it operates as a 'method' of that object. If you have a few minutes, dig up 'Self the video', skip the intro and watch how objects/methods are pulled apart and stuck together. That's the conceptual basis for the object system and it's pretty common for libraries to take advantage of changing `this` to a different object (e.g. `this` is the target element in a jQuery event handler). Opinions are mixed on whether this is ultimately a good idea, but it's part of the language. Having come from Python to Javascript, I consider this to be explicit and a feature rather than a code smell. I dislike when a language's include constructs dump everything into the local namespace and the `this` is implicit because it means that I can't look at a piece of code in isolation without IDE support and figure out where a particular reference is resolving. If it really bothers you, coffeescript uses @ in place of this: Product::make = () -> @mill() @drill() @fill()

silentbicycle 16y ago

To me, Javascript seems headed in the direction of Self, not Lisp. Not a bad place to end up, by any means, but why do people think Javascript is trying to be Lisp in particular? (I know Eich was influenced by Lisp, but so were ML and Smalltalk.) Sometimes I wonder if people just mean, "Wow, Javascript is actually a really expressive, dynamic language, once you get past all the idiosyncratic DOM stuff", but don't know enough other non-ALGOL languages to see that expressiveness isn't just a Lisp thing. Because hey, it doesn't have s-expressions, macros/static metaprogramming, an explicit compile-time phase at all, etc. It has much more in common with Lua or Self than Lisp. It could have been a really awesome language if the browser wars hadn't stunted its growth.

grayrest 16y ago
> why do people think Javascript is trying to be Lisp in particular? The reason I said lisp is because Brendan more or less always mentions he wanted to implement a scheme interpreter but Netscape marketing insisted that it look like Java. As for more closely resembling Self/Lua, I'd largely agree if for nothing other than the obvious object system similarities. On the other hand, I think the idiosyncrasies of javascript like `this` and call/apply, the enforced n-arity of functions, and a lot of the 'convert it to a string' fallbacks (think lisp 1) were attempts at fitting lisp concepts onto the self-like object system. Of course, I have no basis for this so I'm probably wrong, but it makes me feel better when I have to explain them. I will note that JS is moving into limited metaprogramming with the harmony proxies proposal. I also consider destructuring (another harmony proposal) to be a more functional concept than self/lua, but I actually don't know where that started.

eastgate 16y ago

I don't think we should refight the question of encapsulation here. Some people think encapsulation-by-convention is adequate, others don't. I'm also positing Crockford-style modules.(Since it's pretty clear from the context that I'm following Crockford, you might assume that I know about the Javascript/LISP connection.) The question remains: is repeated use of "this" this.Mill(); this.Drill(); this.Fill(); simply semantic vinegar, or does it suggest that the object is not doing its job -- or that we need a new object?

grayrest 16y ago
The problem is that you're applying C++ sensibilities to a prototype OO language. `this` doesn't refer to the current class, but to the current object. There are no classes and no methods. Functions don't even really belong to the object they're written in. You can easily rebind (using call/apply) a function to a different object so that it operates as a 'method' of that object. If you have a few minutes, dig up 'Self the video', skip the intro and watch how objects/methods are pulled apart and stuck together. That's the conceptual basis for the object system and it's pretty common for libraries to take advantage of changing `this` to a different object (e.g. `this` is the target element in a jQuery event handler). Opinions are mixed on whether this is ultimately a good idea, but it's part of the language. Having come from Python to Javascript, I consider this to be explicit and a feature rather than a code smell. I dislike when a language's include constructs dump everything into the local namespace and the `this` is implicit because it means that I can't look at a piece of code in isolation without IDE support and figure out where a particular reference is resolving. If it really bothers you, coffeescript uses @ in place of this: Product::make = () -> @mill() @drill() @fill()