11–20 of 137 posts
Kind of a side note to the posting, but I just have to say: Please make your usage of parens consistent. If you aren't going to use them, don't use them everywhere. Here is an example of what I'm talking about: if isAir cx, cy, cz + 1 then addPlane('near', block) Should be: if isAir cx, cy, cz + 1 then addPlane 'near', block Personally, I use them everywhere because I like having the stronger visual clue that this is…
Kind of a side note to the posting, but I just have to say: Please make your usage of parens consistent. If you aren't going to use them, don't use them everywhere. Here is an example of what I'm talking about: if isAir cx, cy, cz + 1 then addPlane('near', block) Should be: if isAir cx, cy, cz + 1 then addPlane 'near', block Personally, I use them everywhere because I like having the stronger visual clue that this is…
Not allowing parens would mess up the usage of anonymous functions.
@mitsuhiko Not gonna happen ;) Forbidding shadowing altogether is a huge win, and a huge conceptual simplification. How arrogant! You'd think he'd step back for a second and consider the suggestion, but it sounds like he's on autopilot.
There are lots of people throwing in their $0.02 on how the language should work without having joined the mailing list or seen any discussions on the thought process behind its features.
I'm not saying the suggestion made isn't reasonable, but I can understand glib replies like this from the author that don't make too much effort to explain his stance more than 140 characters.
Earlier quoted context omitted.
Not allowing parens would mess up the usage of anonymous functions.
Not sure I understand you or maybe you don't understand me. I was talking about using parens for method/functional calls, not getting rid of them from CS.
doSomething(->
# stuff happens
), onerrorI didn't want to change the default semantics, but I wanted to have a way for the programmer to be safe if they wanted to, so I created the `using` keyword for function declarations.
You explicitly declare what you intend to overwrite in the lexical scope, including overwriting nothing at all with `using nil`.
Earlier quoted context omitted.
Nope, I get it, you were suggesting ":=" as a replacement for the "nonlocal" keyword in Python. I'm not sure how my comments demonstrate any lack of reading comprehension. All I said about ":=" and "nonlocal" is that they are overly complicated once you accept that top-level variables can have wide scope. Obviously, plenty of folks managed to write bug-free code in Python before "nonlocal" was invented. I'm not sayin…
> Obviously, plenty of folks managed to write bug-free code in Python before "nonlocal" was invented. Python has the inverse behavior of CoffeeScript. So that was never an issue.
Earlier quoted context omitted.
Not sure I understand you or maybe you don't understand me. I was talking about using parens for method/functional calls, not getting rid of them from CS.
I understand. If you don't have parens on method calls, how could you use an anonymous function that is not the last parameter? For example: doSomething(-> # stuff happens ), onerror
Earlier quoted context omitted.
Not sure I understand you or maybe you don't understand me. I was talking about using parens for method/functional calls, not getting rid of them from CS.
I understand. If you don't have parens on method calls, how could you use an anonymous function that is not the last parameter? For example: doSomething(-> # stuff happens ), onerror
In coffeescript you can do any of the following, or a few other variants:
doSomething ->
stuff
, onerror
doSomething(->
stuff
, onerror
)
doSomething (->
stuff
), onerror
doSomething(
->
stuff
onerror
)
doSomething (-> stuff), onerror top_level_variable = null
f = ->
top_level_variable = "hello"
f()
console.log top_level_variable # prints hello@mitsuhiko Not gonna happen ;) Forbidding shadowing altogether is a huge win, and a huge conceptual simplification. How arrogant! You'd think he'd step back for a second and consider the suggestion, but it sounds like he's on autopilot.
I really don't understand why this isn't being fixed: doesn't global by default break encapsulation? I'm probably missing something, but this is the main reason I haven't tried coffeescript yet.