views:

37

answers:

3

Didn't think carefully about this post before submitting. Apologies.

+1  A: 

Your second example is invalid:

return{       
        init();
    }

The { ... } defines an object literal which must contain key-value pairs, like { foo: 'bar' }.

casablanca
+1  A: 

Your first example will do the stuff within init and return undefined.

Your second example is invalid. I think you wanted:

return init()

without curly braces. This will return the result of init (which you haven't specified). In both cases, setup and moreSetup never get called, so I'm not sure why they're there.

You've left out a lot of details, but my answer right now is: if the caller needs to do something with the result of init you'll need to go with option #2.

Rob Sobers
A: 

No offense meant, but this seems like a somewhat confused question. As others have noted, you shouldn't have the brackets around init() in the second example. And when you say function setup() { ... } you're just defining the function, not calling it -- meaning in this example the function never gets called.

But the main thing I'm posting this answer to try to address is this: "Call init function vs. returning that function call". It is incorrect to think that you are "returning the function call" in the second example. When you say return init(), first init() is called and returns some value, and then your foo function returns the value returned by init().

So that's the question you should be asking. Do I just want foo to call init, or do I want foo to call init and return the value that init returns? That's the difference between the two (once the other errors are removed).

Tim Goodman