--- Ursprüngliche Nachricht ---
Von: "Brian Cully" <bcully@gmail.com>
An: ruby-talk@ruby-lang.org (ruby-talk ML)
Betreff: Re: cleaner Ruby in a rails view
Datum: Fri, 3 Mar 2006 01:38:38 +0900
In lisp, nil is the empty set, and can be enumerated in the standard
ways.
In ObjC, and, I believe, Smalltalk, nil swallows all messages and
returns nil.
This is /exceedingly/ useful in writing very small amounts of code, and
I am highly irritated that ruby didn't get this right, because it leads
to tons and tons of small error checks that are otherwise un-needed.
"Catches more errors" isn't supposed to be the answer in the ruby
idiom, it's just another case of relying on static type checks instead
of proper testing, which is exactly what we're not supposed to be
doing, right? Otherwise we'd all be using java because rigid typing
"catches more errors".
I would love for ruby's nil to behave properly, as it does in lisp and
objc. You can ask nil anything, but all you're going to get back is nil.
I would love for ruby's nil to behave properly, as it does in lisp and
objc. You can ask nil anything, but all you're going to get back is nil.
Which one behave more properly? Lisp, or Objective-C? Since they
have different behavior for nil[1]. For your information, you can define
something like nil in Objective-C by yourself, using the combination
of BlankSlate and method_missing. Or you can even hack the
interpreter to make nil behave "properly"[2]. It's pretty easy.
matz.
[1] Try (1+ nil) in your Lisp REPL. In Lisp, nil is just a (), not
that something which returns nil for every request, like one in
Objective-C.
[2] But I'm sure you will soon find out making nil behave like you
want is a pretty bad idea. Trust me. I did it 10 years ago. It
swallowed so many errors, and made my debugging horrible. Perhaps
a separated special value dedicated for the purpose might be
better.
···
In message "Re: cleaner Ruby in a rails view" on Fri, 3 Mar 2006 01:38:38 +0900, "Brian Cully" <bcully@gmail.com> writes:
The only time this nil problem occurs for me is with rails views. With
all other ruby (about half my time is spent in ruby and the other half
web apps) code, I never have the nil problem unless I've written bad
code. I feel like web templates should not throw errors if you pass nil
values.
···
On Fri, 2006-03-03 at 03:07 +0900, Yukihiro Matsumoto wrote:
Hi,
In message "Re: cleaner Ruby in a rails view" > on Fri, 3 Mar 2006 01:38:38 +0900, "Brian Cully" <bcully@gmail.com> writes:
>I would love for ruby's nil to behave properly, as it does in lisp and
>objc. You can ask nil anything, but all you're going to get back is nil.
Which one behave more properly? Lisp, or Objective-C? Since they
have different behavior for nil[1]. For your information, you can define
something like nil in Objective-C by yourself, using the combination
of BlankSlate and method_missing. Or you can even hack the
interpreter to make nil behave "properly"[2]. It's pretty easy.
matz.
[1] Try (1+ nil) in your Lisp REPL. In Lisp, nil is just a (), not
that something which returns nil for every request, like one in
Objective-C.
[2] But I'm sure you will soon find out making nil behave like you
want is a pretty bad idea. Trust me. I did it 10 years ago. It
swallowed so many errors, and made my debugging horrible. Perhaps
a separated special value dedicated for the purpose might be
better.
The only time this nil problem occurs for me is with rails views. With
all other ruby (about half my time is spent in ruby and the other half
web apps) code, I never have the nil problem unless I've written bad
code. I feel like web templates should not throw errors if you pass nil
values.
Probably the best thing is to do whatever's necessary in the
controller to make sure the template can coast. So you could, for
example, put list.items (or whatever) in @items, making sure in
advance that it's an empty array if there aren't any.
David
···
On Fri, 3 Mar 2006, Charlie Bowman wrote:
On Fri, 2006-03-03 at 03:07 +0900, Yukihiro Matsumoto wrote:
Hi,
In message "Re: cleaner Ruby in a rails view" >> on Fri, 3 Mar 2006 01:38:38 +0900, "Brian Cully" <bcully@gmail.com> writes:
>I would love for ruby's nil to behave properly, as it does in lisp and
>objc. You can ask nil anything, but all you're going to get back is nil.
Which one behave more properly? Lisp, or Objective-C? Since they
have different behavior for nil[1]. For your information, you can define
something like nil in Objective-C by yourself, using the combination
of BlankSlate and method_missing. Or you can even hack the
interpreter to make nil behave "properly"[2]. It's pretty easy.
matz.
[1] Try (1+ nil) in your Lisp REPL. In Lisp, nil is just a (), not
that something which returns nil for every request, like one in
Objective-C.
[2] But I'm sure you will soon find out making nil behave like you
want is a pretty bad idea. Trust me. I did it 10 years ago. It
swallowed so many errors, and made my debugging horrible. Perhaps
a separated special value dedicated for the purpose might be
better.
Remember that you can always declare Helper methods that deal with the nils for you too.
James Edward Gray II
···
On Mar 2, 2006, at 1:06 PM, dblack@wobblini.net wrote:
Hi --
On Fri, 3 Mar 2006, Charlie Bowman wrote:
The only time this nil problem occurs for me is with rails views. With
all other ruby (about half my time is spent in ruby and the other half
web apps) code, I never have the nil problem unless I've written bad
code. I feel like web templates should not throw errors if you pass nil
values.
Probably the best thing is to do whatever's necessary in the
controller to make sure the template can coast. So you could, for
example, put list.items (or whatever) in @items, making sure in
advance that it's an empty array if there aren't any.
Just to illustrate a point about Rails, I had a similar problem. Some
other code allowed a record to be posted to the DB w/o a good
referential link. IOW, the FK in the record pointed to a missing
record in the linked to table. The Rails view just spit out an
attribute of the linked table and that caused the app to crash because
table1.table2 was nill and table1.table2.field => 'field' was not a
valid method of nil.
So I tried the trick posted earlier and it cleaned it up nicely. I'm
sure that this problem comes up all the time, and there are probably
better ways to handle it, but this abstraction was quite nice:
In the controller's helper, I added a method_missing dispatcher:
module MycontrollerHelper
def method_missing(methodname, *args)
"MISSING RECORD"
end
end
In the view: (in my case rxml)
xml << (table1.table2 || self).field
Hopefully, you have no other need for method_missing in your view.
I'd be interested in others take on this common problem.
Ed
···
On 3/2/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Fri, 3 Mar 2006, Charlie Bowman wrote:
> The only time this nil problem occurs for me is with rails views. With
> all other ruby (about half my time is spent in ruby and the other half
> web apps) code, I never have the nil problem unless I've written bad
> code. I feel like web templates should not throw errors if you pass nil
> values.
Probably the best thing is to do whatever's necessary in the
controller to make sure the template can coast. So you could, for
example, put list.items (or whatever) in @items, making sure in
advance that it's an empty array if there aren't any.
I think that is the best answer so far....but that seems to go against
everything that makes ruby so great. Something just doesn't feel right
about creating an object just to say that it's empty. I guess I should
ask this on the rails list, but I like this list much better , Is is
possible to add methods to the nil class in only the views? If so, that
would be awsome!
>
> Probably the best thing is to do whatever's necessary in the
> controller to make sure the template can coast. So you could, for
> example, put list.items (or whatever) in @items, making sure in
> advance that it's an empty array if there aren't any.
I think that is the best answer so far....but that seems to go against
everything that makes ruby so great. Something just doesn't feel right
about creating an object just to say that it's empty. I guess I should
ask this on the rails list, but I like this list much better , Is is
possible to add methods to the nil class in only the views? If so, that
would be awsome!
Probably the best thing is to do whatever's necessary in the
controller to make sure the template can coast. So you could, for
example, put list.items (or whatever) in @items, making sure in
advance that it's an empty array if there aren't any.
Charlie Bowman
Programmer
Castle Branch Inc.
Hi Charlie,
I think that David's plan is a good one. I also think that his answer has less to do with Ruby and more to do with the appropriate use of the Model-View-Controller framework (if that's the right word).
As I understand it, the role of the controller is to be the setup guy for the view. You really want to have as little significant Ruby code as you can in the view, and that's what David's answer is getting at. Make the controller ensure that the view has an Array to deal with rather than let the view worry about what you've given it.
Probably the best thing is to do whatever's necessary in the
controller to make sure the template can coast. So you could, for
example, put list.items (or whatever) in @items, making sure in
advance that it's an empty array if there aren't any.
I think that is the best answer so far....but that seems to go against
everything that makes ruby so great.
That doesn't say much for all the other answers
Something just doesn't feel right about creating an object just to
say that it's empty. I guess I should ask this on the rails list,
but I like this list much better , Is is possible to add methods
to the nil class in only the views? If so, that would be awsome!
I suppose you could engineer a way to do that, but it sounds awfully
fragile, and like an awful lot of trouble to go to. I'd rather
normalize the data to an array (or whatever) and then just let each
array take care of itself.
I guess I am being a little picky. ruby and rails both are the best at
what they do and it's hard to watch it fall short ( in my very picky
eyes ) in this one area. I am going to work on adding a plugin to rails
that will fix the nil problem. At least then I won't have to call a
helper method, rescue nil, or create an empty object just to display a
view. This has been a great discussion! It's too bad that it wasn't on
the rails list...
> Something just doesn't feel right about creating an object just to
> say that it's empty. I guess I should ask this on the rails list,
> but I like this list much better , Is is possible to add methods
> to the nil class in only the views? If so, that would be awsome!
I suppose you could engineer a way to do that, but it sounds awfully
fragile, and like an awful lot of trouble to go to. I'd rather
normalize the data to an array (or whatever) and then just let each
array take care of itself.
I guess I am being a little picky. ruby and rails both are the best at
what they do and it's hard to watch it fall short ( in my very picky
eyes ) in this one area. I am going to work on adding a plugin to rails
that will fix the nil problem. At least then I won't have to call a
helper method, rescue nil, or create an empty object just to display a
view. This has been a great discussion! It's too bad that it wasn't on
the rails list...
Something just doesn't feel right about creating an object just to
say that it's empty. I guess I should ask this on the rails list,
but I like this list much better , Is is possible to add methods
to the nil class in only the views? If so, that would be awsome!
I suppose you could engineer a way to do that, but it sounds awfully
fragile, and like an awful lot of trouble to go to. I'd rather
normalize the data to an array (or whatever) and then just let each
array take care of itself.
You know, I don't much monitor the rails list but I think that maybe this is something that you would want to run by those folks before you make any big design decisions. The folks over there really do spend a lot of time on rails-specific issues and you'll probably get more discussion over there if not better. I'd be curious to hear what they'd say about this myself since I've been where (I suspect) you are before.
