3 ms·

Katy: CoffeeScript Combinators

36 points by jashkenas 15y ago

jashkenas 15y ago
The other side of the same coin, for the curious: https://github.com/jashkenas/coffee-script/issues/1495 https://github.com/jashkenas/coffee-script/issues/1495
- latchkey 15y ago
  The fact that someone could come along and create a working solution without having to add/change the syntax of CoffeeScript is great.
udp 15y ago
Handy, but I don't see the point in this being anything to do with CoffeeScript until it's an extension to the syntax itself. It currently seems to be a simple addition to the Function prototype for Javascript, and happens to be written in CoffeeScript (why for something so small I've no idea).
- raganwald 15y ago
  > I don't see the point in this being anything to do with CoffeeScript until it's an extension to the syntax itself. The included .js files will work just fine in JavaScript. So you’re right about that. But we are talking about convenience methods and the aesthetics of code, as opposed to some infrastructure functionality (like an async library) or domain-specific functionality (like a state machine mixin). It’s just a feeling on my part, but it makes much more sense to me in CoffeeScript than it does in JavaScript. It’s easier to write anonymous lambdas in CoffeeScript, so it’s cleaner to use .K and .T in CoffeeScript than if I have to encumber a line of code with braces and return keywords. I wrote jQuery Combinators in old-fashioned JavaScript, so I can’t really dispute your suggestion, just share why I wrote it to appeal to CoffeeScript users.
thurn 15y ago
Somewhat related question: Do these fluent interfaces provide any real advantage over named parameters? The wikipedia example of: config.setColor("blue").setHeight(17) seems like it could just as easily be written: config.update(color="blue", height=17)
- raganwald 15y ago
  For updates and initialization, I wonder the same thing. In a discussion about adding chaining syntax to CoffeeScript, one of the contributors wondered about libraries that handle traversing a structure for you: foo.update color: ‘blue’ suffix: ‘singular' barCollection: color: ‘green’ suffix: ‘plural’ This is probably far superior for fairly static tree navigation.
  - politician 15y ago
    Aren't JavaScript objects supposed to be unordered sets? Why is that example equivalent to `foo.color('blue').suffix('singular').barCollection.color('green').suffix('plural')`? (Is it?)
    - raganwald 15y ago
      They are unordered. For certain types of updates, the order is immaterial and a hash of attributes could be applied. On the other hand, if you are mutating a tree as you go along, the order is important and you want to call methods and/or functions to traverse and apply side-effects.
- omaranto 15y ago
  I think they don't have any advantage over named parameters and moreover, that they were invented for and mostly used in languages that do not have named parameters, like Java.

36 points by jashkenas 15y ago

The other side of the same coin, for the curious: https://github.com/jashkenas/coffee-script/issues/1495 https://github.com/jashkenas/coffee-script/issues/1495

latchkey 15y ago
The fact that someone could come along and create a working solution without having to add/change the syntax of CoffeeScript is great.

udp 15y ago

Handy, but I don't see the point in this being anything to do with CoffeeScript until it's an extension to the syntax itself. It currently seems to be a simple addition to the Function prototype for Javascript, and happens to be written in CoffeeScript (why for something so small I've no idea).

raganwald 15y ago
> I don't see the point in this being anything to do with CoffeeScript until it's an extension to the syntax itself. The included .js files will work just fine in JavaScript. So you’re right about that. But we are talking about convenience methods and the aesthetics of code, as opposed to some infrastructure functionality (like an async library) or domain-specific functionality (like a state machine mixin). It’s just a feeling on my part, but it makes much more sense to me in CoffeeScript than it does in JavaScript. It’s easier to write anonymous lambdas in CoffeeScript, so it’s cleaner to use .K and .T in CoffeeScript than if I have to encumber a line of code with braces and return keywords. I wrote jQuery Combinators in old-fashioned JavaScript, so I can’t really dispute your suggestion, just share why I wrote it to appeal to CoffeeScript users.

thurn 15y ago

Somewhat related question: Do these fluent interfaces provide any real advantage over named parameters? The wikipedia example of: config.setColor("blue").setHeight(17) seems like it could just as easily be written: config.update(color="blue", height=17)

raganwald 15y ago
For updates and initialization, I wonder the same thing. In a discussion about adding chaining syntax to CoffeeScript, one of the contributors wondered about libraries that handle traversing a structure for you: foo.update color: ‘blue’ suffix: ‘singular' barCollection: color: ‘green’ suffix: ‘plural’ This is probably far superior for fairly static tree navigation.
- politician 15y ago
  Aren't JavaScript objects supposed to be unordered sets? Why is that example equivalent to `foo.color('blue').suffix('singular').barCollection.color('green').suffix('plural')`? (Is it?)
  - raganwald 15y ago
    They are unordered. For certain types of updates, the order is immaterial and a hash of attributes could be applied. On the other hand, if you are mutating a tree as you go along, the order is important and you want to call methods and/or functions to traverse and apply side-effects.
omaranto 15y ago
I think they don't have any advantage over named parameters and moreover, that they were invented for and mostly used in languages that do not have named parameters, like Java.