#select { |r| (r.speed and r.speed > 300) or (r.range and r.range < 900) or (r.service_date and r.service_date < Date.today) }
select { |r| r.speed > 300 or r.range < 900 or r.service_date < Date.today rescue false }
You should be able to just write:
#select { |r| r.speed > 300 or r.range < 900 or r.service_date < Date.today }
I'm great with that goal really, I just don't think changing Ruby semantics is the way to get there.
Anyway, I hear ya, James. You want me to quit messin' around with NilClass.
Here's my new idea. What about solving this with default values for columns? If speed was defaulting to 0 instead of nil, we wouldn't have a problem. That seems to me to be what these example's intend anyway.
Am I crazy?
James Edward Gray II
···
On Mar 4, 2006, at 7:34 PM, Jamey Cribbs wrote:
Dave Burt wrote:
You can subclass NilClass, but it has no allocator, so you'd have to define your own, and such an object still wouldn't be considered false in conditionals. There is only one nil, and only one false. So there is no point in subclassing NilClass.
Yeah, I tried some of the same stuff Logan did in his email and finally realized that NilClass won't let you subclass it.
But, what if I did something like this:
class KBNil
def method_missing(a,b)
nil
end
def nil?
true
end
end
Then, since, nil and false are the only things that don't evaluate to true, if you do:
k = KBNil.new
puts 'True!' if k > 300 or 800 < 900 # True!
puts 'False!' unless k > 300 or 800 < 900 # False!
puts 'False!' unless k =~ /bob/ # False!
puts 'False!' unless k < Date.today # False!
k.nil? # true
I'm just thinking off the top of my head, but what do you think about this?
Jamey
Maybe. NULL is not equal to zero in SQL DBs for similar reasons why 0 and "" aren't false in ruby. (Consider if you want the product of all values in a given column, if NULLs are true NULLs this will cause no problems, if NULLs are zeros well then your product is all messed up) Of course if you know its ok for your data to have 0 as a sane default that's another thing altogether. The other issue when you really really care about NULLs in my experience is doing outer joins. Which since KirbyBase doesn't really do joins (AFAIK) by itself, maybe it doesn't matter in this case.
···
On Mar 4, 2006, at 11:25 PM, James Edward Gray II wrote:
On Mar 4, 2006, at 7:34 PM, Jamey Cribbs wrote:
#select { |r| (r.speed and r.speed > 300) or (r.range and r.range < 900) or (r.service_date and r.service_date < Date.today) }
select { |r| r.speed > 300 or r.range < 900 or r.service_date < Date.today rescue false }
You should be able to just write:
#select { |r| r.speed > 300 or r.range < 900 or r.service_date < Date.today }
I'm great with that goal really, I just don't think changing Ruby semantics is the way to get there.
Anyway, I hear ya, James. You want me to quit messin' around with NilClass.
Here's my new idea. What about solving this with default values for columns? If speed was defaulting to 0 instead of nil, we wouldn't have a problem. That seems to me to be what these example's intend anyway.
Am I crazy?
James Edward Gray II
I realized, after I sent that, that my solution is *not* equivalent. Guess that's a good argument for your way of doing things Jamey. 
James Edward Gray II
···
On Mar 4, 2006, at 10:25 PM, James Edward Gray II wrote:
On Mar 4, 2006, at 7:34 PM, Jamey Cribbs wrote:
#select { |r| (r.speed and r.speed > 300) or (r.range and r.range < 900) or (r.service_date and r.service_date < Date.today) }
select { |r| r.speed > 300 or r.range < 900 or r.service_date < Date.today rescue false }
Jamey Cribbs wrote:
Dave Burt wrote:
You can subclass NilClass, but it has no allocator, so you'd have to define your own, and such an object still wouldn't be considered false in conditionals. There is only one nil, and only one false. So there is no point in subclassing NilClass.
Yeah, I tried some of the same stuff Logan did in his email and finally realized that NilClass won't let you subclass it.
But, what if I did something like this:
class KBNil
def method_missing(a,b)
nil
end
def nil?
true
end
end
Then, since, nil and false are the only things that don't evaluate to true, if you do:
k = KBNil.new
puts 'True!' if k > 300 or 800 < 900 # True!
puts 'False!' unless k > 300 or 800 < 900 # False!
Oops! That should read:
puts 'False!' unless k > 300 and 800 < 900 False!
Jamey
Jamey, I like this. Seems much safer to me.
···
On 3/4/06, Jamey Cribbs <jcribbs@netpromi.com> wrote:
But, what if I did something like this:
class KBNil
def method_missing(a,b)
nil
end
def nil?
true
end
end
Jamey Cribbs wrote:
k = KBNil.new
#...
k.nil? # true
That would be a lie. There can only be one nil.
Cheers,
Dave
James Edward Gray II wrote:
#select { |r| (r.speed and r.speed > 300) or (r.range and r.range < 900) or (r.service_date and r.service_date < Date.today) }
select { |r| r.speed > 300 or r.range < 900 or r.service_date < Date.today rescue false }
I realized, after I sent that, that my solution is *not* equivalent. Guess that's a good argument for your way of doing things Jamey.
Well, I just wanted to thank you for starting this whole discussion. I *really* like getting feedback on KirbyBase and your post has resulted in some great ideas from people concerning this nil issue.
Bottom line is that I'm going to work on finding a way to satisfy your request to not override NilClass#method_missing while keeping the simplicity of KirbyBase's query expressions.
Thanks again for bringing this up.
Jamey
···
On Mar 4, 2006, at 10:25 PM, James Edward Gray II wrote:
On Mar 4, 2006, at 7:34 PM, Jamey Cribbs wrote:
And thank you for listening! 
James Edward Gray II
···
On Mar 5, 2006, at 9:23 AM, Jamey Cribbs wrote:
James Edward Gray II wrote:
On Mar 4, 2006, at 10:25 PM, James Edward Gray II wrote:
On Mar 4, 2006, at 7:34 PM, Jamey Cribbs wrote:
#select { |r| (r.speed and r.speed > 300) or (r.range and r.range < 900) or (r.service_date and r.service_date < Date.today) }
select { |r| r.speed > 300 or r.range < 900 or r.service_date < Date.today rescue false }
I realized, after I sent that, that my solution is *not* equivalent. Guess that's a good argument for your way of doing things Jamey.
Well, I just wanted to thank you for starting this whole discussion. I *really* like getting feedback on KirbyBase and your post has resulted in some great ideas from people concerning this nil issue.
Bottom line is that I'm going to work on finding a way to satisfy your request to not override NilClass#method_missing while keeping the simplicity of KirbyBase's query expressions.
Thanks again for bringing this up.
Jamey Cribbs wrote:
James Edward Gray II wrote:
I realized, after I sent that, that my solution is *not* equivalent.
Guess that's a good argument for your way of doing things Jamey.
Well, I just wanted to thank you for starting this whole discussion. I
*really* like getting feedback on KirbyBase and your post has resulted
in some great ideas from people concerning this nil issue.
Bottom line is that I'm going to work on finding a way to satisfy your
request to not override NilClass#method_missing while keeping the
simplicity of KirbyBase's query expressions.
I may be jumping in the deep dark waters of overengineering,
but how about just proxying the call? Instead of:
r.speed # => 3
You would have
r.speed # <#KBDBField:0x...>
r.speed.value # 3
r.speed + 1 # 4
The KBDBField (it is just fun to say fast) proxies all of
its requests to the value object unless said object is nil.
Alternatively, NULL = NullClass.new is not a terrible idea
Thanks again for bringing this up.
Jamey
E
···
--
Posted via http://www.ruby-forum.com/\.
Trans wrote:
# :title: NullClass
#
# NullClass is essentially NilClass but it differs in one
# important way. When a method is called against it that it
# deoesn't have, it will simply return null value rather then
# raise an error.
class NullClass #< NilClass
class << self
def new
@null ||= NullClass.allocate
end
end
def inspect ; 'null' ; end
def nil? ; true ; end
def null? ; true ; end
def (key); nil; end
def method_missing(sym, *args)
return nil if sym.to_s[-1,1] == '?'
self
end
end
module Kernel
def null
NullClass.new
end
end
class Object
def null?
false
end
end
Thanks, Trans! I really like this. It makes sense to just create one null object, like nil does.
Jamey
E. Saynatkari wrote:
Jamey Cribbs wrote:
James Edward Gray II wrote:
I realized, after I sent that, that my solution is *not* equivalent. Guess that's a good argument for your way of doing things Jamey.
Well, I just wanted to thank you for starting this whole discussion. I
*really* like getting feedback on KirbyBase and your post has resulted
in some great ideas from people concerning this nil issue.
Bottom line is that I'm going to work on finding a way to satisfy your
request to not override NilClass#method_missing while keeping the
simplicity of KirbyBase's query expressions.
I may be jumping in the deep dark waters of overengineering,
but how about just proxying the call? Instead of:
r.speed # => 3
You would have
r.speed # <#KBDBField:0x...>
r.speed.value # 3
r.speed + 1 # 4
The KBDBField (it is just fun to say fast) proxies all of
its requests to the value object unless said object is nil.
Hmm, this is an interesting idea. I think I'll chew on this one a little bit.
Thanks.
Jamey
Trans wrote:
class NullClass #< NilClass
Thanks Trans! I wrote a little module from this called HungryNil, that
you can use to selectively turn nill values into nulls, in a method
chain.
eg:
nil.n #=> null
2.358.n #=> 5
nil.round #=> method missing error
nil.n.round #=> null
2.358.n.round #=> 2
···
--
Posted via http://www.ruby-forum.com/\.
nil.n #=> null
2.358.n #=> 5
nil.round #=> method missing error
nil.n.round #=> null
2.358.n.round #=> 2
sorry, I forgot the link: <a
href="http://jchris.mfdz.com/articles/2006/03/17/hungrynil">HungryNil</a>
···
--
Posted via http://www.ruby-forum.com/\.