2 ms·

If you're regularly declaring a bunch of anon functions in an array I'd hate to use your code. And your first example is an object declaration, which I have no

If you're regularly declaring a bunch of anon functions in an array I'd hate to use your code. And your first example is an object declaration, which I have no beef with. The console.log is the rare time I'd probably use it. In the end, if you think normal function declaration is a "syntactic hack" we're simply not going to agree. I've used a fair few different languages and to me the distinction between a plain old function and a closure is a useful distinction that helps me read the code quicker. By declaring it as a variable, you're making it hard to decide which it will be as well. And deeply coupling code for no good reason. This is the other thing I can't understand. I can't even MOVE your function without worrying about side effects. On a side note, my original post is going up and down in votes like a yo-yo.

ephemeralgomi 13y ago
async.js has 'waterfall' and 'parallel', both of which take an array of functions, and it's (imo) much clearer to declare them as anonymous functions inline than make named functions and then pass an array of names to it. I would say that that makes me someone who regularly declares a bunch of anonymous functions in an array. If it's a pattern you haven't used, I can certainly understand being wary of it at first. But being wary is different than being prescriptive. There is always more to learn.
jameshart 13y ago
I suspect the vote yo-yoing may be to do with dismissing the possible value of declaring functions inside functions - on a website run by a company called Y Combinator. I think the difference here is that you see function Foo() { ... } as a 'normal' function declaration. I see it as a syntax which hides the truth - that that is actually putting var Foo = function Foo() { .. }; at the top of its scope. It's a special syntax for the special case of "I want this function to have this name and be bound to a variable with the same name for the whole of its enclosing scope". But JavaScript permits me to do lots of OTHER things with functions, and pretending it can't doesn't help me write better JavaScript code. functions are the ONLY way in JavaScript to restrict the scope of a name. How can you talk about the risks of moving things if you aren't even taking advantage of JavaScript's only mechanism to create safely encapsulated name scopes?
- mattmanser 13y ago
  When did I say I didn't use the convention for namespaces? I'm talking about simple code structure. You need a function. Do you put it in a var or not. I have nothing against closures or namespaces or object declaration or many of the million other things you can twist objects in js to do. What I hate is this: var checkValid = function(item) { return item!= blah; } When it should be: function checkValid(item) { //blah } Stop accusing me of a position you've made up in your head.

ephemeralgomi 13y ago

async.js has 'waterfall' and 'parallel', both of which take an array of functions, and it's (imo) much clearer to declare them as anonymous functions inline than make named functions and then pass an array of names to it. I would say that that makes me someone who regularly declares a bunch of anonymous functions in an array. If it's a pattern you haven't used, I can certainly understand being wary of it at first. But being wary is different than being prescriptive. There is always more to learn.

jameshart 13y ago

I suspect the vote yo-yoing may be to do with dismissing the possible value of declaring functions inside functions - on a website run by a company called Y Combinator. I think the difference here is that you see function Foo() { ... } as a 'normal' function declaration. I see it as a syntax which hides the truth - that that is actually putting var Foo = function Foo() { .. }; at the top of its scope. It's a special syntax for the special case of "I want this function to have this name and be bound to a variable with the same name for the whole of its enclosing scope". But JavaScript permits me to do lots of OTHER things with functions, and pretending it can't doesn't help me write better JavaScript code. functions are the ONLY way in JavaScript to restrict the scope of a name. How can you talk about the risks of moving things if you aren't even taking advantage of JavaScript's only mechanism to create safely encapsulated name scopes?

mattmanser 13y ago
When did I say I didn't use the convention for namespaces? I'm talking about simple code structure. You need a function. Do you put it in a var or not. I have nothing against closures or namespaces or object declaration or many of the million other things you can twist objects in js to do. What I hate is this: var checkValid = function(item) { return item!= blah; } When it should be: function checkValid(item) { //blah } Stop accusing me of a position you've made up in your head.