3 ms·

Why? What is so bad about having your conditionals be explicit? What happens when you need an "else" branch? Is not having a person for the given ID an error,

Why? What is so bad about having your conditionals be explicit? What happens when you need an "else" branch? Is not having a person for the given ID an error, is it a "do nothing", or does it mean to create a new person? What does the callback version do if you forget to make your index unique, and end up with multiple people with the same ID; does it get run multiple times? The version that returns a Maybe<Person> at least has an obvious proper response (throw an error).

thedufer 13y ago
Coming from working with node.js, this feels very strange. How do I call a callback in the else case? It looks nice and all, but I don't see a way to make this work if db calls are asynchronous. Any ideas?
- anonymoushn 13y ago
  Pass two callbacks, or make your callback begin with if(err). Which looks suspiciously like a null check.
masklinn 13y ago
> What happens when you need an "else" branch? Then you use one, but null checks generally aren't cases of if/else conditionals, they're more along the lines of "either I have one or mayday mayday". Sometimes slightly softened into "either I have one or use this default thing"
- tbrownaw 13y ago
  more along the lines of "either I have one or mayday mayday". That would be the Perl way of my $person = $data_source->get_person($id) or die "No person available"; ie, there's code to be executed (to raise the error) in the case that there is no person. The callback structure from the article doesn't allow for this.
wpietri 13y ago
We make something explicit when we want to call attention to it. Otherwise, we should make it implicit. Attention is a limited commodity, and I think it's worth preserving for the important things. Sometimes it really is worth reminding people, "Hey, this could be null!" But a lot of the time that is boring. To me this often comes back to favoring meaning over mechanism. The higher up I go in code, the more I want it to be about what the system means, not the particular mechanism I've chosen to make it work. E.g., Computers may be implemented via impure silicon, but most of the time we can forget that. I try to apply that to any sort of mechanism.
anonymoushn 13y ago
Why? Because people won't write null checks some of the time even if they need to. Of course, this solution to that problem introduces a bunch of other problems that you've pointed out, and it would be much better for one's sanity to just use an option/maybe.
InclinedPlane 13y ago
Because once it's possible for an object to be null defensive programming means that you need to check damned near everywhere. After every method call, for example. And that's very, very cumbersome to maintain and very non-DRY.
demallien 13y ago
I tend to consider "if" statements to be a bit like "goto" statements - that is, they can sometimes be useful, but mostly the intent of your code will be clearer if you can avoid them. Use with parsimony.

thedufer 13y ago

Coming from working with node.js, this feels very strange. How do I call a callback in the else case? It looks nice and all, but I don't see a way to make this work if db calls are asynchronous. Any ideas?

anonymoushn 13y ago
Pass two callbacks, or make your callback begin with if(err). Which looks suspiciously like a null check.

masklinn 13y ago

> What happens when you need an "else" branch? Then you use one, but null checks generally aren't cases of if/else conditionals, they're more along the lines of "either I have one or mayday mayday". Sometimes slightly softened into "either I have one or use this default thing"

tbrownaw 13y ago
more along the lines of "either I have one or mayday mayday". That would be the Perl way of my $person = $data_source->get_person($id) or die "No person available"; ie, there's code to be executed (to raise the error) in the case that there is no person. The callback structure from the article doesn't allow for this.

wpietri 13y ago

We make something explicit when we want to call attention to it. Otherwise, we should make it implicit. Attention is a limited commodity, and I think it's worth preserving for the important things. Sometimes it really is worth reminding people, "Hey, this could be null!" But a lot of the time that is boring. To me this often comes back to favoring meaning over mechanism. The higher up I go in code, the more I want it to be about what the system means, not the particular mechanism I've chosen to make it work. E.g., Computers may be implemented via impure silicon, but most of the time we can forget that. I try to apply that to any sort of mechanism.

anonymoushn 13y ago

Why? Because people won't write null checks some of the time even if they need to. Of course, this solution to that problem introduces a bunch of other problems that you've pointed out, and it would be much better for one's sanity to just use an option/maybe.

InclinedPlane 13y ago

Because once it's possible for an object to be null defensive programming means that you need to check damned near everywhere. After every method call, for example. And that's very, very cumbersome to maintain and very non-DRY.

demallien 13y ago

I tend to consider "if" statements to be a bit like "goto" statements - that is, they can sometimes be useful, but mostly the intent of your code will be clearer if you can avoid them. Use with parsimony.