Issue #7978 has been reported by alexeymuranov (Alexey Muranov). ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978 Author: alexeymuranov (Alexey Muranov) Status: Open Priority: Normal Assignee: Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-02-27 15:01
on 2013-02-27 15:02
Issue #7978 has been updated by alexeymuranov (Alexey Muranov). Right now i am creating my own helper method `int_from_bool` to be used in an HTML form :). ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37151 Author: alexeymuranov (Alexey Muranov) Status: Open Priority: Normal Assignee: Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-02-27 15:47
Issue #7978 has been updated by Eregon (Benoit Daloze). I agree true/false#to_i would be nice and used it on some occasions. ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37152 Author: alexeymuranov (Alexey Muranov) Status: Open Priority: Normal Assignee: Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-02-27 20:07
Issue #7978 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected Assignee set to matz (Yukihiro Matsumoto) Ruby is not C. 0 is not false. false is not 0. nil has its role as a default value, true/false are not. Matz. ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37162 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-02-27 21:11
Issue #7978 has been updated by alexeymuranov (Alexey Muranov). matz (Yukihiro Matsumoto) wrote: > Ruby is not C. 0 is not false. false is not 0. In some respects they are similar, and 0 and 1 are often used in relation to logical operation. For example, the characteristic function of a set P is defined as χ_P(x) = 1 if x∈P is true χ_P(x) = 0 if x∈P is false The simplest boolean algebra consists of 0 and 1 with the usual algebraic operations mod 2. ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37163 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-02-27 21:57
Well, yes: ruby is not C and false is not 0. But why false could not be converted to 0 by #to_i ? 27.02.2013 23:07 "matz (Yukihiro Matsumoto)" < matz@ruby-lang.org> : > Matz. > Target version: next minor > > true.to_i > NoMethodError: undefined method `to_i' for true:TrueClass > > This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values.
on 2013-02-27 23:05
Issue #7978 has been updated by phluid61 (Matthew Kerwin). funny_falcon (Yura Sokolov) wrote: > Well, yes: ruby is not C and false is not 0. But why false could not be > converted to 0 by #to_i ? That seems to imply that the reverse should hold, but (({!!0 => true})). Similarly, why should true.to_i return 1, and not -1 (as in Visual Basic) or 43 or 0 (which is also a truthy value)? It makes sense that if such to- (and maybe from-) conversions are required, they should be bundled in a Module that explicitly defines the mappings. ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37166 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-02-28 00:29
Issue #7978 has been updated by alexeymuranov (Alexey Muranov). phluid61 (Matthew Kerwin) wrote: > funny_falcon (Yura Sokolov) wrote: > > Well, yes: ruby is not C and false is not 0. But why false could not be > > converted to 0 by #to_i ? > > That seems to imply that the reverse should hold, but (({!!0 => true})). 1. I do not think there is a rule that such fuzzy typecasting in Ruby has to be invertible: "".to_i.to_s # => "0" 2. !!x is not one of Ruby type casting methods. If Ruby had a function Boolean(x), it would be natural to define it as !!x, but each class would need to define its own typecasting method. In my opinion, 0.to_b would have to be false. > > Similarly, why should true.to_i return 1, and not -1 (as in Visual Basic) or 43 or 0 (which is also a truthy value)? 3. 1 is simpler than 43 or -1. This is the usual convention of boolean algebra that 0 cannot be false and 1 is true. The logical AND becomes simply the multiplication (mod 2). If it is false that you have some object, you have 0 of it. :) ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37170 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-02-28 06:23
Dne 27.2.2013 15:00, alexeymuranov (Alexey Muranov) napsal(a): > Category: core > > > true.to_i > NoMethodError: undefined method `to_i' for true:TrueClass > > This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. > =end > > > Actually I am wondering the opposite, why nil.to_i is possible? It does not make any sense to me. Vít
on 2013-02-28 10:51
Issue #7978 has been updated by alexeymuranov (Alexey Muranov). phluid61 (Matthew Kerwin) wrote: > That seems to imply that the reverse should hold, but (({!!0 => true})). Then what about !!false.to_s # => true ? There is no reason for fuzzy typecasting to preserve true-ish-ness. ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37191 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-03-01 17:51
Issue #7978 has been updated by alexeymuranov (Alexey Muranov). phluid61 (Matthew Kerwin) wrote: > > Similarly, why should true.to_i return 1, and not -1 (as in Visual Basic) or 43 or 0 (which is also a truthy value)? If some event is going to happen with probability 1, it is almost true that it will happen. If it is going to happen with probability 0, it is almost false that it will happen. ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37230 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-03-14 08:49
Issue #7978 has been updated by alexeymuranov (Alexey Muranov). I understand however that there can be a problem if one wants, for example, to use `true`, `false`, `nil` for ternary logic http://en.wikipedia.org/wiki/Three-valued_logic . ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37594 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-03-14 08:55
Issue #7978 has been updated by matz (Yukihiro Matsumoto). What kind of problem do you imagine? I cannot think of any. Matz. ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37595 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
on 2013-03-14 08:59
Issue #7978 has been updated by alexeymuranov (Alexey Muranov). I mean, my suggestion can cause problems if one uses `true`, `false`, `nil` for ternary logic, because `nil.to_i` and `false.to_i` would be both `0`. According to Wikipedia, in ternary logic context, it is common to represent `false` by `-1`. ---------------------------------------- Feature #7978: boolean to_i https://bugs.ruby-lang.org/issues/7978#change-37596 Author: alexeymuranov (Alexey Muranov) Status: Rejected Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: next minor =begin The current behavior is the following: > nil.to_i => 0 > false.to_i NoMethodError: undefined method `to_i' for false:FalseClass > true.to_i NoMethodError: undefined method `to_i' for true:TrueClass This does not look very consistent to me. I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1. I think those are fairly common numeric values for False and True. These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values. =end
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.