5 ms·

I guess it comes down to preferences in readability. Personally I agree that not putting too much logic in anonymous functions makes it more readable. I write

by casperc 13y ago

I guess it comes down to preferences in readability. Personally I agree that not putting too much logic in anonymous functions makes it more readable. I write my own code that way, but some might disagree. I don't care about whether functions are above or below where they are used, as long as it is consistent - but event then it is a minor thing. And since it isn't enforced by the language (e.g. like in Clojure where you have to def the var/function above the reference) it is going to vary across code bases anyway. I don't really think either solves callbacks, nor that callbacks is a problem to be solved. Most comes down to pros and cons seen through the filter of your personal preferences. Sure you can use a language that compiles to javascript. Does the pros outweigh the cons for you? Great, use it/too bad move right along. Not everything is right or wrong, good or bad - in fact most things aren't.

ulisesrmzroche 13y ago
Thing is that it actually matters in JS because declaring a function this way triggers the hoisting mechanism, so named functions are in scope within the entire function in which it is declared, regardless of block nesting. If one isn't careful, and because JS doesn't have the visual delineator of blocks, instead all these rules you have to memorize, this could easily could lead to bugs, especially in large code-bases. I think it's good to rely on closures to keep from polluting your scopes and to not use uneccesary function names, which is going to lead to one giant imperative statement (the one with the sequence of commands for the computer to perform) rather than a lot of little functions that you can pass around. Secrets of the JS ninja goes really in depth about this.
- esailija 13y ago
  There is no such thing as an actual hoisting mechanism. Yes, declared functions are available anywhere in the surrounding scope, just like in any other language. It would be ridiculous if for example you couldn't call a method in Java inside another method unless it was syntactically placed before the target. Global scope pollution is completely irrelevant here - declarations are available in the surrounding scope, not global. If the surrounding scope is global (which it never is in node.js), then that's your problem.
  - ulisesrmzroche 13y ago
    I don't think that's true about the hoisting mechanism. The javascript interpreter looks ahead to find all the var and functions and hoists them to the top of the function. I don't how know Java deals with forward-references, it was already considered passe before I even got into this stuff. Also, where did I write anything about global scope? I said it was good to rely on closures to keep from polluting your scopes, and that there was no need for with unnecessary function names. You're literally belittling me out on things I didn't even write. Am I upvote-target practice here or something?
    - deleted 13y ago
      [deleted]
  - streptomycin 13y ago
    test() def test(): print "Hello."
  - kvb 13y ago
    In the ML family of languages (e.g. OCaml, F#) declarations are only visible to code that occurs syntactically later. This has obvious disadvantages, but also the benefit of making dependencies obvious.
    - esailija 13y ago
      Yes I fell into the "all languages" trap. Maybe "most mainstream languages" is more in line with what I meant. :P

by casperc 13y ago

ulisesrmzroche 13y ago

Thing is that it actually matters in JS because declaring a function this way triggers the hoisting mechanism, so named functions are in scope within the entire function in which it is declared, regardless of block nesting. If one isn't careful, and because JS doesn't have the visual delineator of blocks, instead all these rules you have to memorize, this could easily could lead to bugs, especially in large code-bases. I think it's good to rely on closures to keep from polluting your scopes and to not use uneccesary function names, which is going to lead to one giant imperative statement (the one with the sequence of commands for the computer to perform) rather than a lot of little functions that you can pass around. Secrets of the JS ninja goes really in depth about this.

esailija 13y ago
There is no such thing as an actual hoisting mechanism. Yes, declared functions are available anywhere in the surrounding scope, just like in any other language. It would be ridiculous if for example you couldn't call a method in Java inside another method unless it was syntactically placed before the target. Global scope pollution is completely irrelevant here - declarations are available in the surrounding scope, not global. If the surrounding scope is global (which it never is in node.js), then that's your problem.
- ulisesrmzroche 13y ago
  I don't think that's true about the hoisting mechanism. The javascript interpreter looks ahead to find all the var and functions and hoists them to the top of the function. I don't how know Java deals with forward-references, it was already considered passe before I even got into this stuff. Also, where did I write anything about global scope? I said it was good to rely on closures to keep from polluting your scopes, and that there was no need for with unnecessary function names. You're literally belittling me out on things I didn't even write. Am I upvote-target practice here or something?
  - deleted 13y ago
    [deleted]
- streptomycin 13y ago
  test() def test(): print "Hello."
- kvb 13y ago
  In the ML family of languages (e.g. OCaml, F#) declarations are only visible to code that occurs syntactically later. This has obvious disadvantages, but also the benefit of making dependencies obvious.
  - esailija 13y ago
    Yes I fell into the "all languages" trap. Maybe "most mainstream languages" is more in line with what I meant. :P