4 ms·

The example with the message could just be msg('hello everyone').to( list).except('John').send().then... where send() returns a promise. That is, the message cr

The example with the message could just be msg('hello everyone').to( list).except('John').send().then... where send() returns a promise. That is, the message creates an object that is getting modified until it hits the send method and then it is done. Maybe it is just a too simple example to get a point across, but I would want to see an example where this would not work.

hn_throwaway_99 9y ago
Agreed. The builder pattern is well established and useful, and is a lot simpler to understand (and less bug prone) than what is being proposed here.
alangpierce 9y ago
My impression is the goal of this library is to make it a little cleaner than the builder pattern because you don't need the `.send()` at the end. Arguably, it's nice to make the syntax a little more concise if the library is there to hide all of the complicated details from you. That said, I get uneasy when reading code like the example send('hello everyone!').to('friends').except('john'); since it doesn't follow my mental model of how programs execute. It's shorter than the builder pattern, but, at least to me, less understandable because there's more magic going on.
- bryanrasmussen 9y ago
  I liked it because it reminded me of Ruby's more English like syntax, however someone else made the same comment where I work about it being a source of possible confusion so that is probably true. I guess otherwise it would need to be something like send('hello everyone').to('friends', 'John'); but now you don't understand what 'John' does unless you read the code - which,I know, realistically people don't always make their methods match the names so you don't really know that except('John') does what you might assume until you read it as well. But in a theoretical world that was as we would like it to be you could reason from the method name to what the method actually does.
Can_Not 9y ago
You could instead have then and catch actually create and execute the promise. Then you could write without send (unless you really wanted to): > await msg('hello everyone').to( list).except('John')
baddox 9y ago
I would prefer that API anyway, because it would allow writing reusable code that generates the unsent objects. This is a killer feature of ORMs like Active Record (although in that case you don’t need an explicit “execute” method because it decides to execute the query when you attempt to iterate on the object.)

hn_throwaway_99 9y ago

Agreed. The builder pattern is well established and useful, and is a lot simpler to understand (and less bug prone) than what is being proposed here.

alangpierce 9y ago

My impression is the goal of this library is to make it a little cleaner than the builder pattern because you don't need the `.send()` at the end. Arguably, it's nice to make the syntax a little more concise if the library is there to hide all of the complicated details from you. That said, I get uneasy when reading code like the example send('hello everyone!').to('friends').except('john'); since it doesn't follow my mental model of how programs execute. It's shorter than the builder pattern, but, at least to me, less understandable because there's more magic going on.

bryanrasmussen 9y ago
I liked it because it reminded me of Ruby's more English like syntax, however someone else made the same comment where I work about it being a source of possible confusion so that is probably true. I guess otherwise it would need to be something like send('hello everyone').to('friends', 'John'); but now you don't understand what 'John' does unless you read the code - which,I know, realistically people don't always make their methods match the names so you don't really know that except('John') does what you might assume until you read it as well. But in a theoretical world that was as we would like it to be you could reason from the method name to what the method actually does.

Can_Not 9y ago

You could instead have then and catch actually create and execute the promise. Then you could write without send (unless you really wanted to): > await msg('hello everyone').to( list).except('John')

baddox 9y ago

I would prefer that API anyway, because it would allow writing reusable code that generates the unsent objects. This is a killer feature of ORMs like Active Record (although in that case you don’t need an explicit “execute” method because it decides to execute the query when you attempt to iterate on the object.)