Hi there, So. What is a value ? What is an object ? What are the benefits in distinguishing ? I feel like we should not stick to the implementation level to understand the difference, because, in Ruby, everything (almost) is an object. My understanding is that the value of an object is something abstract and immutable that captures the current state of the object. I feel like this is a well agreed on notion, for example within RPC mechanisms when the notion of "by value" versus "by reference" is used. When something is passed "by value", it is very clear that the object whose value was passed is not going to be modified by the invoked procedure. Now, some class instances don't require an explicit choice: "by value" or "by reference", because it does not matter. This is the case for all instances of the Integer class, as well as for true, false, nil and so on. I tend to think of objects of such classes as "values". The Ruby String class is an interesting example. A beginner frequent error is to forget that a Ruby String object is mutable (i.e. is not a value). I believe that in Java they distinguish things: String : Immutable StringBuf : Mutable To get back to the original post, the issue is whether true? and false? should test the "value" of the object *or* its semantic in the context of a boolean expression (its "truth ness"). If you know Ruby enough, you understand that false? makes sense only if it tests the value. If you are a beginner, you probably get confused. On the other hand the current "if xx == false then" should be readable enough for a beginner to understand that the condition is not met if xx is nil. Yours, JeanHuguesRobert EOM At 01:18 12/11/2004 +0900, you wrote: >"Jean-Hugues ROBERT" <jean_hugues_robert / yahoo.com> schrieb im Newsbeitrag >news:6.0.1.1.0.20041111155014.01b91ff8 / pop.mail.yahoo.com... >> At 22:08 11/11/2004 +0900, you wrote: >> >> >"Jean-Hugues ROBERT" <jean_hugues_robert / yahoo.com> schrieb im >Newsbeitrag >> >news:6.0.1.1.0.20041111082218.040feec0 / pop.mail.yahoo.com... >> >> Hi, >> >> >> >> I think things should stay the way they are, here is >> >> why. >> >> >> >> Things are a little complex about truthness/falseness. >> >> One has to distinguish the "value" of an object from >> >> its "truthness". >> > >> >I'm not sure whether I follow you here: an object *is* the value. >There >> >is no such thing as a value that is distinct from the object. An >object >> >is interpreted as in boolean contexts according to certain rules (false >> >and nil => false, all others true); you could call this convention >> >"truthness", yes. >> >> I don't agree. I don't think that an object IS a value. >> >> An object is more than a value, it is made of: >> an identity >> a value (or state, or attributes, or ...) >> a behavior >> Well... that's the way I learned OO. > >Hm, I think we use a different notion of "value" here. I'd say that in >Ruby every value is an object - as opposed to Java for example, where >there is a distinction between POD's (int, char, long...) and objects. > >> Two objects can sometime have the same "value", this >> is how == compares for equality. > >#== and #equal? are completely independent of values: they form a >convention about when two instances are considered equivalent. For class >Object they have to share the same identity, i.e., every instance is >equivalent to itself only. For other classes (take structs as an example) >equivalence is defined recursively via equivalence of instance variables. > >> When I draw a line between "object" and "value" it is >> about those special objects that compare equal to themselves >> only. These are always immutable objects. > >That last statement is not true: > >class Foo > attr_accessor :bar >end > >Instances of Foo will only be equal to themselfs but they are not >immutable. This is because the inherit default behavior of Object. > >Neither immutablility nor the definition of equivalence of Fixnums make >them special. What makes Fixnum special is the way those instances are >created and treated internally in the Ruby interpreter (which is merely an >implementation detail from the perspective of the language). But >otherwise they are completely normal - there is no such concept as in >Java, where you can have objects and POD's. Consider this: > >class Fixnum > def eql?(x) false end > def ==(x) false end >end > >>> 1 == 1 >=> true >>> 1 == 2 >=> false >>> class Fixnum >>> def eql?(x) false end >>> def ==(x) false end >>> end >=> nil >>> 1 == 1 >=> false >>> 1 == 2 >=> false > >You can change the definition of Fixnum equivalence at your discretion. >Of course, many things would break if you do, but that's another story. > >> For example, >> no two objects can have the same value 3, because 3 >> is an immutable integer. The same is true for true, false, >> nil. On the other hand, two different strings can both >> be valued "3". So, in my mind, 3 is a value, whereas >> "3" is an object (whose initial value is "3"). To me >> values are objects with some semantic restrictions. > >Don't let yourself be fooled by the syntax: the char sequence '3' refers >an object that, in numerical calculations, behaves like the number 3 (i.e. >the mathematical concept). The char sequence '"3"' referns an object that >contains the given characters literally. Again, from the perspective of >the language Ruby, it's an implementation detail, that the object >accessible via '3' is always the same: > >>> 3.id >=> 7 >>> 3.id >=> 7 >>> 3.id >=> 7 >>> 3.id >=> 7 >>> 3.id >=> 7 > >while it's not for '"3"': > >>> "3".id >=> 134992688 >>> "3".id >=> 134985020 >>> "3".id >=> 134977700 >>> "3".id >=> 134972816 >>> "3".id >=> 134969516 > >Of course it makes good sense to make the instance immutable so nobody can >change the state of the instance that the literal 3 refers. You can treat >the object accessible via '3' much the same like others although there are >some restrictions due to the implementation: > >>> 3.send( :+, 3 ) >=> 6 >>> 3.to_s >=> "3" >>> 3.class >=> Fixnum > >> >> Only nil and false are "false" from a "truthness" >> >> perspective. All other objects are "true". >> >> >> >> For true? and false? to be somehow usefull, I first felt >> >> that they should relate to the "truthness" of the >> >> object, not its "value". That is very different from >> >> nil? (it checks the value of the object, only The nil >> >> object is nil?). >> >> >> >> This leads to: >> >> class Object >> >> def true? ; true ; end >> >> def false? ; not true? ; end >> >> end >> >> class NilClass >> >> def true? ; false ; end >> >> end >> >> class FalseClass >> >> def true? ; false ; end >> >> end >> > >> >You can simplify this to >> > >> >class Object >> > def true?; self end >> > def false?; not true? end >> >end >> > >> >because it's the standard convention. Basically this adds one level of >> >indirection (the method call). >> >> But then: nil.true? => nil; I was expecting true, xxx? methods should >> return a boolean I think. > >That's not necessary in Ruby because all values can be treated >meaningfully in a boolean context (as opposed to Java for example). > >> >> Usage: 1 - Checking truthness >> >> if some_thing.true? then >> >> xxx >> >> end >> >> Usage: 2 - Checking value >> >> if some_thing == true then >> >> xxx >> >> end >> >> >> >> On the other hand, one may consider that >> >> checking the value is what matters most, >> >> versus checking the truthness. >> > >> >I never felt the need for "some_thing == true". In which cases do you >> >need this? >> >> I don't. But the original poster may have a different answer I guess. > >Yeah, probably. > >> >> This leads to: >> >> class Object >> >> def true? ; false ; end >> >> def false? ; false ; end >> >> end >> >> class TrueClass >> >> def true? ; true ; end >> >> end >> >> class FalseClass >> >> def false? ; true ; end >> >> end >> > >> >You can simplify this, too: >> > >> >class Object >> > def true?; TrueClass === self end >> > def false?; FalseClass === self end >> >end >> >> I suspect that this is less efficient. My >> verbose code leverage the efficient method >> dispatching of the interpreter (versus the >> additional === test). > >You're definitely right here. > >> >> Usage: 1 - Checking the truthness >> >> if some_thing then >> >> xxx >> >> end >> >> Usage: 2 - Checking the value >> >> if some_thing.true? then >> >> xxx >> >> end >> >> >> >> Solution 2 (checking values) leads to >> >> code that is slightly smaller (less characters). >> >> Which is probably a good thing by itself. >> >> However, I think that it is fairly unreadable. >> > >> >Yep. I find this quite irritating. When I see "if some_thing.true? >> >then..." I'd expect the truthness of some_thing to be used, not the >> >outcome of the test whether some_thing is actually the instance 'true'. >> > >> >> As a conclusion, I think that the status quo >> >> is the best solution. Instead of a hard to >> >> understand true?/false?, let's keep an explicit >> >> xxx == true when value matters instead of >> >> truthness. >> > >> >.... or "TrueClass === xxx" for that matter. Yes. Totally agree. >> > >> >> My 0.2 Euros. >> > >> >Now we got 0.22 EUR. :-) >> >> You make my day ;-) > >Should I open up a savings account? :-) > >Unfortunately I have to go now, otherwise my answer would have been more >verbose, I guess. But we can continue this tomorrow. :-) > >Kind regards > > robert ------------------------------------------------------------------------- Web: http://hdl.handle.net/1030.37/1.1 Phone: +33 (0) 4 92 27 74 17