JavaScript: what is "this"? • Hacker News Board

Re: JavaScript: what is "this"?

#21

Post by WilliamLP » Sun, Mar 21, 2010, 9:02 PM UTC

erlanger wrote: post #19

WilliamLP wrote: post #12

If anyone wonders why every JavaScript framework under the sun rolls its own object system, and they're all incompatible, and almost nobody uses native JavaScript alone anymore, this is one of the reasons.

> rolls its own object system === "Provides convenience functions for working with prototype chains." That has nothing to do with what makes the this keyword special in JavaScript, beyond prototypes affecting this ' properties.

> "Provides convenience functions for working with prototype chains."

Yes, that's pretty much what an object system is, isn't it? It's some convenience behaviour, but it would be nice if the language had a built-in way of doing things that wasn't so inconvenient.

Re: JavaScript: what is "this"?

#22

Post by chromatic » Sun, Mar 21, 2010, 9:19 PM UTC

tumult wrote: post #6

audionerd wrote: post #4

Earlier quoted context omitted.

I think the author is just citing how influential Scheme was to JavaScript's design. In "Coders at Work", page 141, Brendan Eich talks about wanting to build a scheme-like language for the browser. The c-like syntax was adopted because Netscape wanted it to look like Java.

Maybe he wanted to. If that was his goal, I think he failed. Scheme: First-class functions, tail-call elimination, macros, hygienic macros, write and parse the AST directly. JavaScript: First-class functions. Scheme: Immutable arrays and lists, mutable strings. JavaScript: Mutable-only arrays, immutable-only strings. Yes, I have, and have read, Coders at Work. I don't see how it's relevant. JavaScript and Scheme shar…

People compared Perl to Lisp once, briefly, when it was one of the few dynamic languages, but they don't anymore.

They should; Perl 5 compares quite well and Perl 6 fares even better (of the nine fundamental features of a Lisp, lacking only homoiconicity). See the book Higher-Order Perl, for example.

http://hop.perl.plover.com/

Re: JavaScript: what is "this"?

#23

Post by erlanger » Sun, Mar 21, 2010, 9:34 PM UTC

WilliamLP wrote: post #21

erlanger wrote: post #19

Earlier quoted context omitted.

> rolls its own object system === "Provides convenience functions for working with prototype chains." That has nothing to do with what makes the this keyword special in JavaScript, beyond prototypes affecting this ' properties.

> "Provides convenience functions for working with prototype chains." Yes, that's pretty much what an object system is, isn't it? It's some convenience behaviour, but it would be nice if the language had a built-in way of doing things that wasn't so inconvenient.

I wasn't disputing that, I'm saying it's irrelevant to the discussion (the commenter implied that prototype modification is related to how this is determined in a given function call).

Re: JavaScript: what is "this"?

#24

Post by tolmasky » Sun, Mar 21, 2010, 9:49 PM UTC

erlanger wrote: post #23

WilliamLP wrote: post #21

Earlier quoted context omitted.

> "Provides convenience functions for working with prototype chains." Yes, that's pretty much what an object system is, isn't it? It's some convenience behaviour, but it would be nice if the language had a built-in way of doing things that wasn't so inconvenient.

I wasn't disputing that, I'm saying it's irrelevant to the discussion (the commenter implied that prototype modification is related to how this is determined in a given function call).

I think it's pretty relevant. For example, something that is absolutely trivial in other languages (making super calls), is incredibly difficult to implement generically in JS, partially because of the way this behaves. This is something every class system (and of course just using prototype chains alone) in JS seems to run into. We ran into it early with Objective-J, and then CoffeeScript had the same problem: http://news.ycombinator.com/item?id=1014524

Re: JavaScript: what is "this"?

#25

Post by axod » Sun, Mar 21, 2010, 9:57 PM UTC

WilliamLP wrote: post #12

If anyone wonders why every JavaScript framework under the sun rolls its own object system, and they're all incompatible, and almost nobody uses native JavaScript alone anymore, this is one of the reasons.

Almost nobody? Seriously? I'd be interested to see some data to back that up.

'this' takes all of about 5 minutes to understand in Javascript. It's pretty logical and there aren't really any surprises. Same with the prototypal inheritance.

Re: JavaScript: what is "this"?

#26

Post by erlanger » Sun, Mar 21, 2010, 10:25 PM UTC

tolmasky wrote: post #24

erlanger wrote: post #23

Earlier quoted context omitted.

I wasn't disputing that, I'm saying it's irrelevant to the discussion (the commenter implied that prototype modification is related to how this is determined in a given function call).

I think it's pretty relevant. For example, something that is absolutely trivial in other languages (making super calls), is incredibly difficult to implement generically in JS, partially because of the way this behaves. This is something every class system (and of course just using prototype chains alone) in JS seems to run into. We ran into it early with Objective-J, and then CoffeeScript had the same problem: http:…

To clarify, you're saying super is difficult to implement in JavaScript? I think the power of JavaScript's design is borne out by how easily one can recreate classical inheritance in the language, a view shared by Crockford.

Re: JavaScript: what is "this"?

#27

Post by vr » Sun, Mar 21, 2010, 10:41 PM UTC

WilliamLP wrote: post #12

If anyone wonders why every JavaScript framework under the sun rolls its own object system, and they're all incompatible, and almost nobody uses native JavaScript alone anymore, this is one of the reasons.

The reason why some frameworks roll out custom object systems is because they try to make JavaScript look like a language with classes, "this" semantics isn't what's driving them. In a language with classes developers are used to "this" being an instance of the current class, and this expectation creates a consfusion in JavaScript. If you don't look at it through the prism of classes, the rule for "this" is pretty simple: "this" is the receiver. Create a function, apply it to any object, and that object will be the receiver available as "this". It's that simple. Now the only confusion left is who's the receiver. In "foo.bar()" like cases it's obvious, and the only remaining case (if you don't count the discouraged "with" statement) is "bar()" which calls a function on the global object (like in Python).

Re: JavaScript: what is "this"?

#28

Post by i_tumult » Sun, Mar 21, 2010, 10:50 PM UTC

tumult wrote: post #3

It's not entirely our fault, the language was designed to work like one thing (scheme-like), but look like another (c-like). The baseless assertion rears its head again. People keep repeating this, and it's not true. JavaScript is not Scheme. It's not any more Scheme-like than Java, C++, Python, Perl, or many other languages. Lua and Ruby are far more Scheme-like than JavaScript. I've commented before on people repea…

me smart. me know scheme. me know javascript unlike scheme. me make noise. me smart. ME SMART!

Re: JavaScript: what is "this"?

#29

Post by tolmasky » Sun, Mar 21, 2010, 10:56 PM UTC

erlanger wrote: post #26

tolmasky wrote: post #24

Earlier quoted context omitted.

I think it's pretty relevant. For example, something that is absolutely trivial in other languages (making super calls), is incredibly difficult to implement generically in JS, partially because of the way this behaves. This is something every class system (and of course just using prototype chains alone) in JS seems to run into. We ran into it early with Objective-J, and then CoffeeScript had the same problem: http:…

To clarify, you're saying super is difficult to implement in JavaScript? I think the power of JavaScript's design is borne out by how easily one can recreate classical inheritance in the language, a view shared by Crockford.

I'm not sure I understand. I'm saying specifically that at the very least, this one feature of classical inheritance is not easy to implement and in fact almost always leads to bugs when people try to do it. The truth is that most of the interesting features of classical inheritance are pretty hard to implement:

1. super, as described above

2. private, protected, etc. Never seen this work in js with inheritance

3. inheriting class methods as well as instance methods

If all you care about is the most superficial copying of a superclass' methods, then yeah of course its easy to do in JS, its essentially just prototypal inheritance again. Its arguably just as easy to implement this watered down form of classical inheritance in C as well (or in any language I guess):

struct MySubclass { struct MySuperclass base; int newMember; }

I don't think this is necessarily an argument for elegance however.

The point is, if these are features that everyone has to implement, then at some point you have to say "maybe its not that everyone else is stupid and doesn't get it, but that its an actually worthwhile feature". In fact, they predicted this (which is why class and super are reserved words in JS despite not doing anything), and its supposedly expected to come in the next iteration of JS (as in, the one after the one currently not even implemented yet). So, in 50 years when we get that we'll finally have remedied this issue.

Re: JavaScript: what is "this"?

#30

Post by IgorPartola » Sun, Mar 21, 2010, 11:14 PM UTC

rimantas wrote: post #17

IgorPartola wrote: post #10

Earlier quoted context omitted.

Which is why PHP is so much less flexible than JS. Also try this: $a = 1; function qqq() { global $a; unset( $a ); } qqq(); var_dump( $a ); P.S.: In PHP 5.1.6 calling unset() actually increases memory usage...

global $a in PHP is just another way to write $a =& $GLOBALS['a']; I.e. you just create reference to a global variable. Unsetting reference just breaks the tie between variable name and content.

Exactly, which means that unset( $a ) is not the same thing as unset( $GLOBALS['a'] ). It makes perfect sense, just not a kind of thing you might not expect at first.