Hacker News Reader

Comment by damncabbage | Hacker News Reader

This is great, but I'm a little worried about the custom Maybe function that slipped in about halfway through. Unless it's part of a standard framework (like ActiveSupport), if you use it in your projects you're likely going to find that:

a) Integrating with other codebases that don't use Maybe will result in code with an inconsistent style, and

b) If Maybe (or something like it) catches on enough, you'll hit collisions where two projects or libraries have different ideas of what Maybe means. (Maybe one uses NilClass, the other the custom NullClass, for example.)

(The PHP community has taken this to the extreme, with developers getting burnt over and over again with differing "standard" components using the same set of names.)

View on HN

It indicates that what the author may want is a more expressive type system, one that can do some static verification(e.g. Scala's Option, Haskell's Maybe).

Another way to get the behavior of the described Maybe method is to enforce a coding style where functions require a default return value to be passed in - this lets it be handled in a precise manner and surfaces most problems quickly, without butchering fundamental assumptions of the language.

The real difficulty comes in when you want to enforce a branch for functions that are "rarely null" instead of having them blow up much later when you inevitably forget to handle the null case. A lot of the time the only immediate way to avoid this class of error is to use algorithms that will never stumble over a null(which tends to make them a lot slower) - if you have macros or richer type systems, other things are possible of course.

Also, you can't make a Ruby object falsy. So if you overload #nil? you get fun problems like:

    obj.nil? # => true
    !!obj    # => true

> can't make a Ruby object falsy

You can override ! (see http://www.rubyinside.com/rubys-unary-operators-and-how-to-r... from earlier this week) so !!obj can evaluate to false. But there is still this to solve:

    ruby-1.9.3-p0 :008 > obj ? true : false
     => true 
    ruby-1.9.3-p0 :009 >

If only there was a #to_bool to override...

(For the record: yuck).

I like to use andand, which also encompasses the maybe monad, but in a better way IMHO. http://andand.rubyforge.org/

I'd also like just letting nils be nils :) but good presentation.

Good points. Any idea what a good solution would be?

I think a good solution (for Ruby) would to add something like that to a future Ruby version. These things do conflict with Ruby's core semantics a bit, but they do open the door to some intriguing styles -- as does this: https://github.com/intridea/hashie

I proposed a not-dissimilar idea on ruby-core recently. It got a little support, but was mostly ignored. It can be remarkably difficult to get meaningful changes adopted.

If ruby core shrinks and more of the standard libraries move to gems, it will be easier to just write this sort of thing as a gem and let the best ideas win out. The state_machine gem is a great example of the slow (but very solid) evolution of acts_as_state_machine into a highly useful general ruby library.

I don't know about Ruby but when this occasionally happens to me in Perl the answer is not to import anything and call methods by their package name.

Is there a concept of namespace in Ruby? I did a quick search but I'm still not sure.

Certainly: modules and classes serve as namespaces

  module Foo
    class Bar
    end
  end

Bar is now only accessible as Foo::Bar. You could have a Baz::Bar class that is entirely separate from this Bar.

Reply on news.ycombinator.com