Subject line says it all: nil.id #=> 4 !!!
$ ruby -v
ruby 1.8.1 (2003-12-25) [powerpc-darwin]
$ ruby -e "puts nil.id; puts false.id; puts true.id"
4
0
2
This showed up as a bug in my code when finding records against nil
GOT RESULTS. I’ll need to override NilClass#id. :-/
I can certainly understand rationales for nil.respond_to?(:id) –
everything’s an object, etc., etc. But I also might suggest that the id
of nil shouldn’t be 4?! Shouldn’t nil be able to be used as a
lightweight and/or primitive Null Object?
···
–
Ryan “John” Platte
Custom services, NIKA Consulting
http://nikaconsulting.com/
John Platte wrote:
Subject line says it all: nil.id #=> 4 !!!
$ ruby -v
ruby 1.8.1 (2003-12-25) [powerpc-darwin]
$ ruby -e “puts nil.id; puts false.id; puts true.id”
4
0
2
This showed up as a bug in my code when finding records against nil GOT
RESULTS. I’ll need to override NilClass#id. :-/
I can certainly understand rationales for nil.respond_to?(:id) –
everything’s an object, etc., etc. But I also might suggest that the id
of nil shouldn’t be 4?! Shouldn’t nil be able to be used as a
lightweight and/or primitive Null Object?
Why are you testing the value of nil.id? You know nil is nil
already. The ids are the way they are because the first two bits convey
information.
I suggest you just live with this. And I suggest that if you are
checking the id of nil, your code is likely flawed in concept.
Hal
Subject line says it all: nil.id #=> 4 !!!
$ ruby -v
ruby 1.8.1 (2003-12-25) [powerpc-darwin]
$ ruby -e “puts nil.id; puts false.id; puts true.id”
4
0
2
See ruby.h, look for “#define Qnil” around line 171.
This showed up as a bug in my code when finding records against nil
GOT RESULTS. I’ll need to override NilClass#id. :-/
Why do you need nil’s #object_id to be any particular special value?
I can certainly understand rationales for nil.respond_to?(:id) –
everything’s an object, etc., etc. But I also might suggest that the id
of nil shouldn’t be 4?! Shouldn’t nil be able to be used as a
lightweight and/or primitive Null Object?
What should it be?
Note:
$ ruby -e ‘(0…10).each do |x| puts “#{x}: #{x.object_id}” end’
0: 1
1: 3
2: 5
3: 7
4: 9
5: 11
6: 13
7: 15
8: 17
9: 19
10: 21
In other words, an odd #object_id is a Fixnum, while an even #object_id
is a reference to an Object.
···
John Platte (john.platte@nikaconsulting.com) wrote:
–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
SQL. I’m inheriting from OpenStruct to create an active record object
(inspired by Mr. Rails, but found it a better fit to roll my own
simpler version). It works deliciously except for this – I can plop
SQL results directly into this little Record object, overload behavior
really easily. And the primary key column is called “id”, so that’s
where the primary key info lives.
You’re probably right – I’m copping out of using a real “NullRecord”.
I’ll keep a nose out for more smells and look for the sources of nil
that should be emitting a “NullRecord” instead.
Thanks.
···
On 2004 May 26, at 17:08, Hal Fulton wrote:
This showed up as a bug in my code when finding records against nil
GOT RESULTS. I’ll need to override NilClass#id. :-/
I can certainly understand rationales for nil.respond_to?(:id) –
everything’s an object, etc., etc. But I also might suggest that the
id of nil shouldn’t be 4?! Shouldn’t nil be able to be used as a
lightweight and/or primitive Null Object?
Why are you testing the value of nil.id? You know nil is nil
already. The ids are the way they are because the first two bits convey
information.
I suggest you just live with this. And I suggest that if you are
checking the id of nil, your code is likely flawed in concept.
–
Ryan “John” Platte
Custom services, NIKA Consulting
http://nikaconsulting.com/