4 ms·

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 Ac

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.)

airlocksoftware 15y ago
Good points. Any idea what a good solution would be?
- einhverfr 15y ago
  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.
- grandalf 15y ago
  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 https://github.com/intridea/hashie
  - regularfry 15y ago
    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.
    - grandalf 15y ago
      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.
prosa 15y ago
Also, you can't make a Ruby object falsy. So if you overload #nil? you get fun problems like: obj.nil? # => true !!obj # => true
- deleted 15y ago
  [deleted]
- zwp 15y ago
  > can't make a Ruby object falsy You can override ! (see http://www.rubyinside.com/rubys-unary-operators-and-how-to-redefine-their-functionality-5610.html 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).
chipsy 15y ago
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.
steelaz 15y ago
Is there a concept of namespace in Ruby? I did a quick search but I'm still not sure.
- Confusion 15y ago
  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.
sunkencity 15y ago
I like to use andand, which also encompasses the maybe monad, but in a better way IMHO. http://andand.rubyforge.org/ http://andand.rubyforge.org/ I'd also like just letting nils be nils :) but good presentation.

airlocksoftware 15y ago

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

einhverfr 15y ago
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.
grandalf 15y ago
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 https://github.com/intridea/hashie
- regularfry 15y ago
  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.
  - grandalf 15y ago
    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.

prosa 15y ago

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

deleted 15y ago
[deleted]
zwp 15y ago
> can't make a Ruby object falsy You can override ! (see http://www.rubyinside.com/rubys-unary-operators-and-how-to-redefine-their-functionality-5610.html 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).

chipsy 15y ago

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.

steelaz 15y ago

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

Confusion 15y ago
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.

sunkencity 15y ago

I like to use andand, which also encompasses the maybe monad, but in a better way IMHO. http://andand.rubyforge.org/ http://andand.rubyforge.org/ I'd also like just letting nils be nils :) but good presentation.