JavaScript: Function Invocation Patterns

http://doctrina.org/Javascript-Function-Invocation-Patterns.html

by bazsouthafrica • 14 years ago

123 47 14 years ago

hafabnew• 14 years ago

There's an error in his first 'Function Invocation' example, the answer is 500, not 501.

[Reason: 'this.value++;' in the method invocation refers to obj.value, since 'this' is bound to 'obj'. Only in the innerFunction function invocation does 'this' bind to the global object.]

user24• 14 years ago

Should have mentioned call along with apply.

Not sure these are patterns rather than just language features.

cjfont• 14 years ago

I agree, this is similar to saying that i+=1 and i++ are increment patterns.

andrewflnr• 14 years ago

Well, yes, except complicated enough to merit more explanation.

bengillies• 14 years ago

Exactly. Stuff that's built directly into the language isn't a pattern, it's a feature (perhaps a wart in this case). From Wikipedia [1]:

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application.

[1] http://en.wikipedia.org/wiki/Software_design_pattern

franze• 14 years ago

please see the HN guidelines http://ycombinator.com/newsguidelines.html

  Please don't do things to make titles stand out, like using 
  uppercase or exclamation points, or adding a parenthetical 
  remark saying how great an article is. It's implicit in 
  submitting something that you think it's important.

plus i have a very strong distain about anyone or anything (i.e. headlines) which tell me what i MUST do / know / think... - also the article above is about a very basic language feature of JS that hopefully anyone who has every touched JS already knows about.

camus• 14 years ago

I agree this article is kind of javascript 101. And it doesnt do a great job explaining exactly why things are the way they are in javascript. And these are not patterns , since they are built in the language. It would be like saying using the world class in java is using a pattern... I dont see the point featuring it on HN...

raganwald• 14 years ago

Amusingly, the original title has a spelling mistake: "Javascript: Function Inovcation Patterns."

But enough burying the lede. The issue I have with this title is simple: It's not clear WHY I must know these patterns: The focus of the post is not why I must know them, but rather This post explains the four patterns, how to use them and what to watch out for. Had the post kicked off by explaining that not knowing one or more of these patterns could lead to disaster, I'd be onside with the submission title rewrite (sans emphasis).

tantalor• 14 years ago

It still does: the language is "JavaScript", not "Javascript".

sltkr• 14 years ago

> the article above is about a very basic language feature of JS that hopefully anyone who has every touched JS already knows about.

Hopefully, yes, but I think reality is much more depressing than that. Unfortunately, the JavaScript programmers that don't know probably don't read Hacker News either.

dwj• 14 years ago

Actually, I only have a vague understanding of this and I'm probably what you would call an expert. I have used many of these features in JS, but like the author says it's unintuitive and "wrong" the way javascript does it. Basically OOP is a horrible hack in JS, and this is a very good article explaining various gotchas that I wasn't aware of.

marknutter• 14 years ago

How about instead of hijacking the thread to bitch about guidelines 1% of the HN population knows about you let the down arrow do your talking?

jamesbritt• 14 years ago

Because it helps educate the 99% who might otherwise think this is an acceptable title format.

fatboy• 14 years ago

Not using Javascript frequently enough to justify reading a book on it, I found the article useful. These features have been counterintuitive for me.

dsego• 14 years ago

Katz has an interesting article on this as well: http://yehudakatz.com/2011/08/11/understanding-javascript-fu...

dnc3• 14 years ago

One portion of Douglas Crockford's book "JavaScript: The Good Parts" describes invocation patterns thoroughly.

It might be that the author of the post was inspired by this book. Since he hasn't mentioned it, I did it in case someone wants to know more about the topic (and doesn't know about the book).

jszen• 14 years ago

He does actually refer to Crockfords book roughly half way through.

dnc3• 14 years ago

Nope, he doesn't. :)

willvarfar• 14 years ago

The big bug as I see it is:

   obj = {
     get_name = function() { return "I am an object" },
     func = function() { alert(this.get_name()); }
   }

This looks dandy, and obj.func() works as expected.

but if you pass obj.func as a callback, the this when its invoked will be some other object (by default, the window object):

   button.onclick = obj.func; // bang when invoked

The number of times I got screwed by that. You end up having to have little anonymous functions for all callbacks:

    button.onclick = function(evt) { obj.func(); }

(apologies for bugs; just typing javascript from memory)

(would love to be wrong)

locci• 14 years ago

bind was introduced in ES5 (and previously in most libraries) to fix this

https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

huskyr• 14 years ago

And trivially easy to shim for older browsers. I would really recommend using Function.prototype.bind instead of the 'var self = this' or library bind functions (such as $.proxy), it's just the way it should be written :)

politician• 14 years ago

It clicked for me when I decided that there were no methods and considered all function invocations to be special cases of `apply`. Then the case you mentioned becomes a bog standard case of a property lookup, and the callback becomes a case of `apply(window, [args])`.

tldr: JavaScript has functions, not methods :)

bazsouthafrica4• 14 years ago

This is exactly the catch with respect to function invocation method that I was trying to point out. It seems that in a call back method, `this` gets bound to the global object. I suspect it is because it is called with the same mechanism that is used for function invocation. That being said, I did not use this example because one needs to implement a callback to see the error. My example that I chose in my article was designed so that anyone could just create the JavaScript, fire it up in a browser, and see the error for themselves.

I do however intend to use an example similar to the one you have presented when I cover closures and scoping in JavaScript.

FuzzyDunlop• 14 years ago

There is an easy way to get round this problem, but it is in my opinion a hack. One gets around this problem by assigning a varialbe (by convention, it is named that) to this inside the function

Or use `bind` instead.

emehrkay• 14 years ago

or use call or apply when invoking innerFunction, which he describes later in the article

TazeTSchnitzel• 14 years ago

No mention of strict mode? Come on!

'use strict' makes the this variable undefined in functions invocation.

recursive• 14 years ago

I have yet to find a use for constructors in a real world problem. I've been able to do anything I ever wanted to with object literals. I'm not sure why there is so much emphasis placed on object prototypes.

jlongster3• 14 years ago

He's wrong in the "Constructor Invocation" example.

function Foo(type) { this.type = type; return type; }

var bar = new Foo(5);

`bar` DOES equal 5. When you return something in a constructor, it returns it instead of returning the newly constructed object. This is a neat way for constructing different types of things.

And most of his complaints are just because he doesn't understand how `this` scoping works in javascript. If you don't understand something, don't just blame it on "bad patterns". It might not be the most intuitive, but once you learn it, it's fine. Sure, I have to bind `this` to a different function here and there, but these problems are not that bad in real world javascript.

lhorie3• 14 years ago

> `bar` DOES equal 5

No, it doesn't. Javascript is a bit weird when it comes to return statements inside constructors. `bar` will be equal to `type` only if `(type instanceof Object) == true`. Otherwise, it will be a new object.

    function Foo(type) { this.type = type; return type; }
    console.log(new Foo(/a/));   // Regexp /a/
    console.log(new Foo("a"));   // {type: "a"}
    console.log(new Foo(5));     // {type: 5}
    console.log(new Foo([1,2])); // [1,2]
    console.log(new Foo({a:1})); // {a: 1}

jlongster3• 14 years ago

Huh, you're right. I thought I typed that at the REPL and it gave back 5, but obviously I typed the wrong thing.

Almost all cases that I've used this functionality have been to return a different object. I suppose when you say "new" you're supposed to expect an object, which is why it works that way.

ynniv2• 14 years ago

a good time to point out that calling Object() without "new" returns a new object. This is often unexpected when creating inheritance schemes that chain the parent constructor.

https://github.com/documentcloud/backbone/pull/1269

bazsouthafrica4• 14 years ago

I realise that everyone is critic, but I am sorry: I understand fully how `this` gets bound and how scoping works in Javasscript. And it sucks!

Scoping: Javascript uses C/Java notation but it does not have block scope, only function scope. That to me seems very misleading.

And with regards to `this`, the way function invocation sets `this` differs totally from method invocation. How can this not be a problem!

jlongster3• 14 years ago

> Scoping: Javascript uses C/Java notation but it does not have block scope, only function scope. That to me seems very misleading.

Yes, it is, but we weren't talking about that problem. That is already solved in ES6 with `let`, which is approved and will be available in about a year.

> And with regards to `this`, the way function invocation sets `this` differs totally from method invocation. How can this not be a problem!

Function and method invocation are different things, with different semantics. It's like that in many other languages too. Sure, the way `this` is handles is a problem sometimes, but I think it's overblown.

mcgwiz• 14 years ago

"Complaints"? Wha? Did we read the same article? Except for a few asides, he wasn't complaining. He was explaining.

taybin• 14 years ago

Also makes for a good interview question.

bazsouthafrica4• 14 years ago

Hi Guys

I just want to give you some feedbacks in the comments (I am the author of this article).

Firstly, with regards to the title, I did not read the newsguidlines document - I have submitted links in the way and style that other people did. For sure, in the future, I will follow these guidlines, but this must be a huge problem as lots of people do this.

Secondly, these are patterns (not language features). Yes, I was inspired by Douglas Crockford's book where he describes this as patterns. To me describing them as patterns makes sense: For instance, there is really nothing different about calling a method and a function. If you have to make a difference, then it is a pattern. And because putting new in front of a function also calls that function, it is in my mind a pattern. And in that sense, so is apply.

But I welcome the debate, and thanks for the constructive comments. I will take all these comments into consideration the next time I submit something.

robocat• 14 years ago

Nice article.

I think you are missing a fifth way to call a function, a property accessor function (although I have never used one, so not certain!).

Some mention of how somefunc.bind(someobj) affects the "patterns" might also be worthwhile (although maybe confusing!).

rgbrgb2• 14 years ago

> Invoking a function suspends execution of the current function, passing controls and parameters to the invoked function.

False. JS functions execute asynchronously, without suspending the execution of the current function.

rgbrgb2• 14 years ago

Did I miss something here? Why was this downvoted?

bazsouthafrica4• 14 years ago

I did not downvote your comment, but it is fundamentally incorrect. If your JavaScript program has been designed well, then asynchronisity by using an event driven model is the way to go. But that is very different to what I said about functions stopping the execution of the current function. This is true. For example

var func1 = function() { //Execute something here }

var func2 = function() { //Execute something here func1(); //Stop execution of this function, and rather execute func2 //Execute something here }

I hope the above explains this a bit better.

JavaScript: Function Invocation Patterns

Related Stories