@Crell The beautiful thing about booleans is they force things to be distilled down to yes or no questions. Take that away and you have a language full of 'maybe'. 😆
I find that the language forms the thinking we do about the solutions. And the more clear the language the more clear the thoughts...
Holy shit I think I just talked myself out of using nulls... 🤣
But are they really all the same yes/no question? Success/Failure and Found/NotFound are not the same space, semantically. They get serialized to true/false for storage.
Just like a name and an ID are both "strings", but only as a representation. They're semantically different things.
@maxtappenden@syntaxseed No, I think it's more semantic accuracy. Just like null is problematic because it means "out of bounds", for any bounds, which is sometimes a meaningful value, but it's hard to distinguish. Hence why I recommend replacing null returns with purpose-built enums.
But if we can do that for the unary type, can we for the binary type? Maybe? What are the implications?
It's just me musing aloud at the moment to cause trouble. 🙂
@Crell@syntaxseed I’m struggling with this because I feel like you have a point and it’s the kind of thing I’d usually be a stickler for. But I’m struggling to think of any practical value beyond, “this totally works for my particular brand of crazy and if I let myself / skip my ADHD meds, I could get completely neurotic about this.”
@maxtappenden@syntaxseed "What are the practical advantages?" is what I asked in the first place. 😃
I'd speculate that it would become more natural to pass and return more domain-specific symbols. Like, return AccessDenied rather than "false", which more naturally extends to PartialAccess, or whatever. And those can be objects with methods, for polymorphism.
@Crell@maxtappenden@syntaxseed I’ve tended to throw exceptions for this, however there are many folks these days on the anti-exception bandwagon, and I can see some of their points (i.e., giving up control on one part of your application to another, which the caller might not be aware of). So, returning an enum would be helpful in that the caller can make decisions about what to do, based on different cases of the enum, something that gets unwieldy with lots of exceptions.
@ramsey@maxtappenden@syntaxseed I've written extensively elsewhere on why exceptions are a bad choice for such flow control, especially in PHP where they're so expensive.
@ramsey@Crell@maxtappenden@syntaxseed I don't know if other languages do things differently but it greatly annoys me when exceptions are not included in a throws annotation. For all intents and purposes they are a potential return type. I don't like to use null because it lacks context, but the proper use of exceptions can't be relied upon either. Using enums makes a weird kind of sense. A bit like http status codes.
@Crell@ramsey thank you - I love this kind of thing. Although I do use exceptions I am a stickler for being explicit about the kind of exceptions that are used. There is a biiiig difference between say a runtime exception and a logic exception and a difference still between a domain exception and a systems one. I'm constantly reevaluating what this all means, though, from a practical standpoint.
@Crell I've seen this used to describe arguments. e.g. enum CaseSensitive {Yes, No}. match_string("foo", "bar", CaseSensitive::Yes);
In this case we understand what is going on without having to look at argument names, which we can't do with: match_string("foo", "bar", true); // what does "true" mean in this context?
Those are not the same type (true/false) any more than name, address, id, and description are all "strings." And newer languages tend to make it easy to not just do "everything is a string, hope you know what it is."
@Crell I guess for some things it could be annoying. e.g. has_foo() calls which are by convention yes / no questions. You'd have to find a word that works in all contexts to describe this. e.g. enum Exists may be good for one context, but not exactly the right term for another. Not sure though...
@heiglandreas Sure, just like you can make an enum Null { case null; } 🙂
But what are the larger implications of encouraging people to think differently, in more context-aware ways? eg, Success | Failure, which suggests "wait, why did it fail", etc.
Add comment