Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't overload #nil? in Ruby

paul.rosania.org

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Don't overload #nil? in Ruby

#31

Post by raganwald »

masukomi wrote: post #29
raganwald wrote: post #28

Earlier quoted context omitted.

Speaking as a Ruby user, I think nil and the entire behaviour around truthyness and falseness are wrong. I should be able to create my own nil objects, and I especially would love to be able to create false objects that carry more information. For example (and there are code smells in this, but it gets the idea across): if account = Account.create(params[:account]) ... else complainAbout account.errors end Truthiness…

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 i…

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.

Re: Don't overload #nil? in Ruby

#32

Post by masukomi »

raganwald wrote: post #31
masukomi wrote: post #29

Earlier quoted context omitted.

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 i…

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.

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.

Re: Don't overload #nil? in Ruby

#33

Post by raganwald »

masukomi wrote: post #32
raganwald wrote: post #31

Earlier quoted context omitted.

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.

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.

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

Re: Don't overload #nil? in Ruby

#34

Post by regularfry »

raganwald wrote: post #28
adestefan wrote: post #25

Earlier quoted context omitted.

The ruby people will tell you that ruby's x, where x is power, flexibility, etc., comes from the ability to shoot yourself in the foot so just don't shoot yourself in the foot.

Speaking as a Ruby user, I think nil and the entire behaviour around truthyness and falseness are wrong. I should be able to create my own nil objects, and I especially would love to be able to create false objects that carry more information. For example (and there are code smells in this, but it gets the idea across): if account = Account.create(params[:account]) ... else complainAbout account.errors end Truthiness…

This is the next step for my #blank? proposal over here: http://redmine.ruby-lang.org/issues/5372 - to make #blank? or #null? objects evaluate as false in boolean expressions.

Re: Don't overload #nil? in Ruby

#35

Post by spooneybarger »

bodhi wrote: post #22
mcobrien wrote: post #17

I'm not sure I like it, but this works def nil.method_missing(*args, &block); end So now you can call nil.whatever.you.like and get nil. It's also still falsy, but now every nil value in your app silently works and doesn't throw an error. It's both impressive and scary that Ruby lets you (or that new contractor you're not sure about) change the fundamentals of the language in one line of code.

I recall that this was the default action of Smalltalk? I can't find a reference though, so I am very likely incorrect. In Objective-C nil will absorb any messages too, see the section "Sending Messages to nil" in http://developer.apple.com/library/ios/#DOCUMENTATION/Cocoa/...

It isn't the default action in smalltalk. nil does not silently absorb messages in smalltalk.

Re: Don't overload #nil? in Ruby

#36

Post by sleight42 »

raganwald wrote: post #33
masukomi wrote: post #32

Earlier quoted context omitted.

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.

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 bein…

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.

Re: Don't overload #nil? in Ruby

#38

Post by aphyr »

DanielRibeiro wrote: post #24
bluesnowmonkey wrote: post #21

Having recently worked with a Ruby codebase where anything could be nil at anytime, I consider even references to nil to be a code smell. Developers are inherently prone to ignoring error handling, so they'll happily ignore the fact that Order#customer really means Order#customer_or_nil. And when they see errors in production, they'll slap an andand on it and call it fixed. The code becomes extremely difficult to rea…

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3]. Scala's standard library provides very helpful information on how to replace null with its Maybe class (called Option in Scala). Just take a peek into their collections library[4], and search for Option. [1] http://www.infoq.com/presentations/Nu…

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3].

Do you have a source for this? I was under the impression nil was directly taken from Smalltalk, which derived it from Lisp.

Re: Don't overload #nil? in Ruby

#39

Post by DanielRibeiro »

aphyr wrote: post #38
DanielRibeiro wrote: post #24

Earlier quoted context omitted.

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3]. Scala's standard library provides very helpful information on how to replace null with its Maybe class (called Option in Scala). Just take a peek into their collections library[4], and search for Option. [1] http://www.infoq.com/presentations/Nu…

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3]. Do you have a source for this? I was under the impression nil was directly taken from Smalltalk, which derived it from Lisp.

Wikipedia[1] has the refs:

The null reference was invented by C.A.R. Hoare in 1965 as part of the Algol W language. Hoare later (2009) described his invention as a "billion-dollar mistake":[10][11]

[1] http://en.wikipedia.org/wiki/Null_pointer#Null_pointer

Where:

[10] http://qconlondon.com/london-2009/presentation/Null+Referenc...

[11] http://www.infoq.com/presentations/Null-References-The-Billi...

Yes, the same video I linked above.

Re: Don't overload #nil? in Ruby

#40

Post by aphyr »

DanielRibeiro wrote: post #39
aphyr wrote: post #38

Earlier quoted context omitted.

Nils are a very bad code smell. They come from C's null, which is a billion dollar mistake[1], according to its creator: Tonny Hoare. Specially now that we have monads[2, 3]. Do you have a source for this? I was under the impression nil was directly taken from Smalltalk, which derived it from Lisp.

Wikipedia[1] has the refs: The null reference was invented by C.A.R. Hoare in 1965 as part of the Algol W language. Hoare later (2009) described his invention as a "billion-dollar mistake":[10][11] [1] http://en.wikipedia.org/wiki/Null_pointer#Null_pointer Where: [10] http://qconlondon.com/london-2009/presentation/Null+Referenc... [11] http://www.infoq.com/presentations/Null-References-The-Billi... Yes, the same vide…

Nil was a part of Lisp 1, which is why I was confused. It predates Algol W by seven years. As null references and nil are somewhat different beasts, I'm not sure the criticism "billion dollar mistake" applies fully.
Post reply on HN