Hacker News new | ask | show | jobs
by masukomi 5331 days ago
To me this isn't a problem with nil. This is a problem with the create method. create either returns you the object or something ambiguous (nil). it COULD return you the object or something useful, like an error class, or an error code, or whatever....

If you care enough about the state of what's being returned then it would be trivial to test if the returned object was of the class you were expecting (Account) and if not handle what it did return (some error indication) as appropriate.
1 comments
raganwald 5331 days ago
I'm ok with that. BUT if that's how we want to go, why not ditch truthiness for non-nil objects altogether?My complaint is that truthiness is baked into the language in such an inflexible way.
link
masukomi 5331 days ago
I'm not sure how I feel about that. It just seems so useful to have it, BUT I think there's definitely a strong argument to be made for your proposition.

Alternately, why not just switch to a functional language where, it seems, ambiguity and other related problems rarely make it past the bouncer at the front door.

link
raganwald 5331 days ago
I think this is a design issue that is orthogonal to functional languages or static typing. We could easily create a language where writing "if foo" causes an error when foo doesn't resolve to an instance of Boolean. If we like, we could add coercion to boolean through the #to_b" method (although I have issues with implicit coercion).

At a deep level, I wonder if my issue is with if stamens and boolean operators being magic outside of the object system. Smalltalk gets this right. Scheme gets this right. if "if" is defined in the standard library rather than being magic syntactic construct, we can write our own control primitives:

    provided account = Account.create(params[:account])
      ...
    end
:-)
link
sleight42 5331 days ago
That added flexibility comes at the cost of standardization.

There are practical reasons that we're not all coding in IO. Allowing for the redefinition of control primitives is a slippery slope. In short order, we may have apps that read well to us but aren't clear to others.

link