4 ms·

nil is annoying and should be avoided when possible. nil gives no useful feedback when blowing up and communicates nothing about the intent of the code. Using a

nil is annoying and should be avoided when possible. nil gives no useful feedback when blowing up and communicates nothing about the intent of the code. Using a Guest object is a great use of polymorphism and duck typing, which are great features of Ruby (and object orientation). Having nils all over the place and having to do `if some_obj` all of the time is messy. Your example is pretty simple, so my solution will sound like overkill, but I would use some other type of object such as a Presenter to handle the rendering logic.

3pt14159 12y ago
Naw, you're complicating things. Nil should not be avoided, it should be accepted. If there isn't a current user then don't pretend that there is. Anywhere you are doing `if some_obj` in view code you'll probably be doing `if some_obj.is_a? Guest` or `if some_obj.guest?` anyway. I've worked on very large and well used applications (billions of loads, multiple data centers, hundreds of thousands of lines of code), not that that should really matter to the argument (logical fallacy and all that), but the thing that I've found messes up Rails applications is large model objects ("god objects"), poorly thought out data relationships, and inconsistent assumptions across systems that lead to hacks. Not nils.
- rubiquity 12y ago
  > Anywhere you are doing `if some_obj` in view code you'll probably be doing `if some_obj.is_a? Guest` or `if some_obj.guest?` anyway. Sorry, you're completely wrong. Polymorphism and duck typing exist specifically so that you don't have to do `is_a?` checks. > but the thing that I've found messes up Rails applications is large model objects ("god objects"), How do you think god object models get created in the first place? By not extracting out logic. When you have models that have very different state, you actually have very different objects. Those differences should be extracted into different classes.
Finbarr 12y ago
Agree that `if some_obj` all the time is annoying. Instead, better to introduce semantic helper methods like `if signed_in?` (which incidentally is included with gems like Devise).
- matdes 12y ago
  helpers are awful embrace OO

3pt14159 12y ago

Naw, you're complicating things. Nil should not be avoided, it should be accepted. If there isn't a current user then don't pretend that there is. Anywhere you are doing `if some_obj` in view code you'll probably be doing `if some_obj.is_a? Guest` or `if some_obj.guest?` anyway. I've worked on very large and well used applications (billions of loads, multiple data centers, hundreds of thousands of lines of code), not that that should really matter to the argument (logical fallacy and all that), but the thing that I've found messes up Rails applications is large model objects ("god objects"), poorly thought out data relationships, and inconsistent assumptions across systems that lead to hacks. Not nils.

rubiquity 12y ago
> Anywhere you are doing `if some_obj` in view code you'll probably be doing `if some_obj.is_a? Guest` or `if some_obj.guest?` anyway. Sorry, you're completely wrong. Polymorphism and duck typing exist specifically so that you don't have to do `is_a?` checks. > but the thing that I've found messes up Rails applications is large model objects ("god objects"), How do you think god object models get created in the first place? By not extracting out logic. When you have models that have very different state, you actually have very different objects. Those differences should be extracted into different classes.

Finbarr 12y ago

Agree that `if some_obj` all the time is annoying. Instead, better to introduce semantic helper methods like `if signed_in?` (which incidentally is included with gems like Devise).

matdes 12y ago
helpers are awful embrace OO