These are chat archives for jdubray/sam

19th
Feb 2018
Jean-Jacques Dubray
@jdubray
Feb 19 2018 14:00
@foxdonut this monad style/concept looks promosing, though I am still on the fence, looks like a lot effort for just a bit of elegance.
Jean-Jacques Dubray
@jdubray
Feb 19 2018 14:09
In other words, in SAM the conditions that trigger an acceptor need to be highly visible to be able to reason about the code. The whole point of a monad is to hide that code such that functions can be composed (Action | Acceptor) transparently.
Fred Daoud
@foxdonut
Feb 19 2018 14:18
@jdubray I use crocks on the server/node side, where I have series of asynchronous calls that use libraries with callbacks of the function(err, result) style. So for each (database) call, there could be an error, or there could be no result (which would also be an error in some cases.) This results in a lot of nested if (err) { throw err; } and nested null checks. With crocks, this gets nicely flattened out with calls to .map or .chain instead, where each call only happens on the "success" path. the error vs success handling then only needs to happen in one place, which is the only place where it matters.
Fred Daoud
@foxdonut
Feb 19 2018 14:30
@jdubray I thought a lot over the weekend about the generic Model.present function vs named functions. I will leave Model.present in the SAM example of course. I understand the decoupling, and that actions are just sending plain objects as proposals to the model without any knowledge of what will actually happen with those proposals. I understand that the actions should not be telling the model what to do. Nevertheless, I see drawbacks in that approach on a practical level, namely how it makes the present function somewhat clumsy and brittle in trying to figure out what to do with proposals. On the other hand, I don't see any real drawbacks to using named functions. My mind is open, though. Do you have any real use cases that expose the advantages of the generic present function over named functions?
devin ivy
@devinivy
Feb 19 2018 14:37
i think that @jdubray said the named functions are okay, as long as those functions aren't "acceptors." in the sense that they have the option to reject. at that point it's very similar to vuex, which JJ said is true to SAM.
Fred Daoud
@foxdonut
Feb 19 2018 14:39
ah I see, that makes sense. thanks @devinivy
Janne Siera
@jannesiera
Feb 19 2018 14:48
@foxdonut I'm personally in favor of named functions as well.
@foxdonut @jdubray That said, you could also do something like this (https://gist.github.com/jannesiera/cce8bfcd8e858dd50ad6525b4d7afbeb) to allow for JJ's more dynamic acceptor predicates (where you can check on all proposal values, and not just its name). I don't know if that syntax is any better than if/else/switch statements in a big function, but I just wanted to throw it out there. Only thing is that the predicates can't access the model now, but that's just because I didn't take the time to figure out @foxdonut 's wiring here.
Jean-Jacques Dubray
@jdubray
Feb 19 2018 15:24
@jannesiera yes, that's one step forward, but remember in the model you can use both primed and non primed variables so the conditions to trigger an acceptor would not be general enough if they were to depend solely on the proposal. Again, please beware of syntax over semantics.
Janne Siera
@jannesiera
Feb 19 2018 15:25
@jdubray that's what I was referring to with my last sentence. The model SHOULD be available to the predicate, but I didn't take the time to look at the broader wiring. @foxdonut will be able to fix that.
Jean-Jacques Dubray
@jdubray
Feb 19 2018 15:26
Yes, sorry, I didn't read it until I posted it.
Janne Siera
@jannesiera
Feb 19 2018 15:26
Np
Fred Daoud
@foxdonut
Feb 19 2018 16:14
@jannesiera I would still favour named functions.