This issue also arises in the Annotation system used by Nitro. The
solution there was to use NullClass. Unfortuately it does have the TRUE
conditional issue. I’ve asked matz and nabu about adding NullClass to
Ruby core, but they did not feel it was needed. Perhaps they might
reconsider now that it has come up again?
On Mar 4, 2006, at 11:25 PM, James Edward G. II wrote:
#select { |r| r.speed > 300 or r.range < 900 or r.service_date <
wouldn’t have a problem. That seems to me to be what these
example’s intend anyway.Am I crazy?
James Edward G. II
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 7:34 PM, Jamey C. 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 G. II
Jamey C. wrote:
k = KBNil.new
#…
k.nil? # true
That would be a lie. There can only be one nil.
Cheers,
Dave
: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 ; 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
Logan C. wrote:
not NULL = NULL
Boolean ops involving only TRUE and FALSE work as usual
Ooops, before someone hits me, I made a mistake in the above NULL or
FALSE is NULL not FALSE.
–Apple-Mail-20-8862340–
If only we had a Boolean class we could subclass and/or override.
Oops, that was proposed and shot down.
Dan
On Mar 4, 2006, at 10:25 PM, James Edward G. II wrote:
On Mar 4, 2006, at 7:34 PM, Jamey C. 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. 
James Edward G. II
Trans wrote:
@null ||= NullClass.allocateend
end
end
Thanks, Trans! I really like this. It makes sense to just create one
null object, like nil does.
Jamey
On Mar 5, 2006, at 9:23 AM, Jamey C. wrote:
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.
And thank you for listening! 
James Edward G. II
James Edward G. 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.
Thanks again for bringing this up.
Jamey
Jamey C. wrote:
James Edward G. 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
On 3/4/06, Dave B. [email protected] wrote:
Jamey C. wrote:
What has been kicked around when this question has come up before is for
me to create something like a NULL class and use this to designate a null
value in the database, instead of using nil. This would take care of
having to override NilClass#method_missing. It would bring up a few other
problems, namely, what if someone wants to store the string value NULL in
a field. But I imagine these could be overcome.
If you define a new NULL class, you have the problem of it being true in
conditionals. I think it would be difficult to make it work intuitively, and
impossible to make it as well as the nil.method_missing hack works.
James Edward G. II wrote:
This has been a popular discussion lately, but I just don’t think loading
a database library should fundamentally change the language.As good a point as that is, I think this is KirbyBase’s best option. I think
the risk of nil.method_missing returning nil breaking something is low, as
has been argued in the debates on this list (Guy Decoux?). If it did,
wouldn’t we have heard about it by now?It does probably demand a prominent warning in the README.
I think that the risk is very high. As with JEG2, this would prevent
me from using KirbyBase were I to have something that could use it. I
think that this is a fundamental change to the language and not
desirable.
-austin
E. Saynatkari wrote:
I may be jumping in the deep dark waters of overengineering,
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
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: HungryNil