[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Why do true and false have separate classes

Nit Khair

1/14/2009 1:27:00 PM

This has puzzled me a bit. I googled and came up with responses like --
in any case we use respond_to? for duck typing.

I am writing a program in which some classes behave differently
depending on the data in various columns. Typically, this means
displaying and editing of cells. So true and false are boolean and are
displayed and edited as checkboxes.

Having 2 separate classes really complicated things since i don't want
to define 2 separate renderers and editors for true and false.

Just wondered what the thought behind this was?
--
Posted via http://www.ruby-....
16 Answers

Jason Roelofs

1/14/2009 1:56:00 PM

0

On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com> wrote:
> This has puzzled me a bit. I googled and came up with responses like --
> in any case we use respond_to? for duck typing.
>
> I am writing a program in which some classes behave differently
> depending on the data in various columns. Typically, this means
> displaying and editing of cells. So true and false are boolean and are
> displayed and edited as checkboxes.
>
> Having 2 separate classes really complicated things since i don't want
> to define 2 separate renderers and editors for true and false.
>
> Just wondered what the thought behind this was?
> --
> Posted via http://www.ruby-....
>
>

It's only the core philosophy of Ruby: You have objects send messages
to those objects.
If there weren't a TrueClass and FalseClass, what else would true and false be?

Jason

Nit Khair

1/14/2009 2:07:00 PM

0

Jason Roelofs wrote:
> On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com>
> wrote:
>>
>> Just wondered what the thought behind this was?
>> --
>> Posted via http://www.ruby-....
>>
>>
>
> It's only the core philosophy of Ruby: You have objects send messages
> to those objects.
> If there weren't a TrueClass and FalseClass, what else would true and
> false be?
>
> Jason

I would assume one class named like "Boolean".

TAke for example numbers -- there is only one Fixnum class which can
have many values. Similarly i would assume one Boolean class with values
true and false.
--
Posted via http://www.ruby-....

David A. Black

1/14/2009 2:14:00 PM

0

Hi --

On Wed, 14 Jan 2009, Ruby Rabbit wrote:

> Jason Roelofs wrote:
>> On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com>
>> wrote:
>>>
>>> Just wondered what the thought behind this was?
>>> --
>>> Posted via http://www.ruby-....
>>>
>>>
>>
>> It's only the core philosophy of Ruby: You have objects send messages
>> to those objects.
>> If there weren't a TrueClass and FalseClass, what else would true and
>> false be?
>>
>> Jason
>
> I would assume one class named like "Boolean".
>
> TAke for example numbers -- there is only one Fixnum class which can
> have many values. Similarly i would assume one Boolean class with values
> true and false.

Google for: ruby "boolean class"
This is a borderline perma-thread.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.r...
Coming in 2009: The Well-Grounded Rubyist (http://manning....)

http://www.wis... => Independent, social wishlist management!

pjb

1/14/2009 2:15:00 PM

0

Jason Roelofs <jameskilton@gmail.com> writes:

> On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com> wrote:
>> This has puzzled me a bit. I googled and came up with responses like --
>> in any case we use respond_to? for duck typing.
>>
>> I am writing a program in which some classes behave differently
>> depending on the data in various columns. Typically, this means
>> displaying and editing of cells. So true and false are boolean and are
>> displayed and edited as checkboxes.
>>
>> Having 2 separate classes really complicated things since i don't want
>> to define 2 separate renderers and editors for true and false.
>>
>> Just wondered what the thought behind this was?
>> --
>> Posted via http://www.ruby-....
>>
>>
>
> It's only the core philosophy of Ruby: You have objects send messages
> to those objects.
> If there weren't a TrueClass and FalseClass, what else would true and false be?

You could have a Boolean class with a truth value attribute. But then
you couldn't implement ifTrue: and ifFalse: without circularity.

But even if we kept TrueClass and FalseClass, it would be better to have a common generalization:

(class Boolean
# empty
end)

(class TrueClass < Boolean
# ...
end)

(class FalseClass < Boolean
# ...
end)


So now the OP would be able to define methods at the level of the Boolean class only.
Instead he will have to define his methods at the level of the Object class.

--
__Pascal Bourguignon__

David A. Black

1/14/2009 2:38:00 PM

0

Hi --

On Wed, 14 Jan 2009, Pascal J. Bourguignon wrote:

> Jason Roelofs <jameskilton@gmail.com> writes:
>
>> On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com> wrote:
>>> This has puzzled me a bit. I googled and came up with responses like --
>>> in any case we use respond_to? for duck typing.
>>>
>>> I am writing a program in which some classes behave differently
>>> depending on the data in various columns. Typically, this means
>>> displaying and editing of cells. So true and false are boolean and are
>>> displayed and edited as checkboxes.
>>>
>>> Having 2 separate classes really complicated things since i don't want
>>> to define 2 separate renderers and editors for true and false.
>>>
>>> Just wondered what the thought behind this was?
>>> --
>>> Posted via http://www.ruby-....
>>>
>>>
>>
>> It's only the core philosophy of Ruby: You have objects send messages
>> to those objects.
>> If there weren't a TrueClass and FalseClass, what else would true and false be?
>
> You could have a Boolean class with a truth value attribute. But then
> you couldn't implement ifTrue: and ifFalse: without circularity.
>
> But even if we kept TrueClass and FalseClass, it would be better to have a common generalization:
>
> (class Boolean
> # empty
> end)
>
> (class TrueClass < Boolean
> # ...
> end)
>
> (class FalseClass < Boolean
> # ...
> end)
>
>
> So now the OP would be able to define methods at the level of the Boolean class only.
> Instead he will have to define his methods at the level of the Object class.

I know you know you don't need those parentheses. Is this a LISP
homage? :-)


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.r...
Coming in 2009: The Well-Grounded Rubyist (http://manning....)

http://www.wis... => Independent, social wishlist management!

LaP

1/14/2009 4:19:00 PM

0

David A. Black a écrit :

> I know you know you don't need those parentheses. Is this a LISP
> homage? :-)

At least this helps text editors keep good indentation ;)

LaP

pjb

1/14/2009 7:07:00 PM

0

"David A. Black" <dblack@rubypal.com> writes:

> Hi --
>
> On Wed, 14 Jan 2009, Pascal J. Bourguignon wrote:
>
>> Jason Roelofs <jameskilton@gmail.com> writes:
>>
>>> On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com> wrote:
>>>> This has puzzled me a bit. I googled and came up with responses like --
>>>> in any case we use respond_to? for duck typing.
>>>>
>>>> I am writing a program in which some classes behave differently
>>>> depending on the data in various columns. Typically, this means
>>>> displaying and editing of cells. So true and false are boolean and are
>>>> displayed and edited as checkboxes.
>>>>
>>>> Having 2 separate classes really complicated things since i don't want
>>>> to define 2 separate renderers and editors for true and false.
>>>>
>>>> Just wondered what the thought behind this was?
>>>> --
>>>> Posted via http://www.ruby-....
>>>>
>>>>
>>>
>>> It's only the core philosophy of Ruby: You have objects send messages
>>> to those objects.
>>> If there weren't a TrueClass and FalseClass, what else would true and false be?
>>
>> You could have a Boolean class with a truth value attribute. But then
>> you couldn't implement ifTrue: and ifFalse: without circularity.
>>
>> But even if we kept TrueClass and FalseClass, it would be better to have a common generalization:
>>
>> (class Boolean
>> # empty
>> end)
>>
>> (class TrueClass < Boolean
>> # ...
>> end)
>>
>> (class FalseClass < Boolean
>> # ...
>> end)
>>
>>
>> So now the OP would be able to define methods at the level of the Boolean class only.
>> Instead he will have to define his methods at the level of the Object class.
>
> I know you know you don't need those parentheses. Is this a LISP
> homage? :-)

We can say that yes. I like the parentheses. They help my editor to
implement higher level editing commands (it becomes a structural
editor). It's also a way to remember that Ruby is just a lisp that
has been Matzacred. And a wonder why Ruby users don't use the true
thing, Common Lisp.


--
__Pascal Bourguignon__

Nit Khair

1/14/2009 7:17:00 PM

0

Pascal J. Bourguignon wrote:
> "David A. Black" <dblack@rubypal.com> writes:
>
>> I know you know you don't need those parentheses. Is this a LISP
>> homage? :-)
>
> We can say that yes. I like the parentheses. They help my editor to
> implement higher level editing commands (it becomes a structural
> editor). It's also a way to remember that Ruby is just a lisp that
> has been Matzacred. And a wonder why Ruby users don't use the true
> thing, Common Lisp.

"Matzacred" - rotfl.

I had heard that the true thing was Smalltalk.
--
Posted via http://www.ruby-....

Mike Gold

1/14/2009 7:54:00 PM

0

Pascal J. Bourguignon wrote:
> It's also a way to remember that Ruby is just a lisp that
> has been Matzacred.

Is the intended pun "massacred lisp" ... or "Matz' sacred lisp"?
--
Posted via http://www.ruby-....

pjb

1/14/2009 8:26:00 PM

0

Ruby Rabbit <sentinel.2001@gmx.com> writes:

> Pascal J. Bourguignon wrote:
>> "David A. Black" <dblack@rubypal.com> writes:
>>
>>> I know you know you don't need those parentheses. Is this a LISP
>>> homage? :-)
>>
>> We can say that yes. I like the parentheses. They help my editor to
>> implement higher level editing commands (it becomes a structural
>> editor). It's also a way to remember that Ruby is just a lisp that
>> has been Matzacred. And a wonder why Ruby users don't use the true
>> thing, Common Lisp.
>
> "Matzacred" - rotfl.
>
> I had heard that the true thing was Smalltalk

http://web.archive.org/web/20060522191515/http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-t...

| Subject: Re: Ruby's lisp features.
| From: Yukihiro Matsumoto <matz ruby-lang.org>
| Date: Mon, 13 Feb 2006 13:43:02 +0900
| In-reply-to: 179515
|
| Hi,
|
| In message "Re: Ruby's lisp features."
| on Mon, 13 Feb 2006 02:38:18 +0900, Edward Kenworthy <edward / kenworthy.info> writes:
|
| |I've been programming for more years than I care to remember and am
| |enjoying programming in Ruby (especially on Rails). So far I've found
| |nothing "new" (to me) in Ruby, with the exception of the lisp-like
| |features and that's something I'd really like to explore.
|
| |Anyone able to point me to a resource please?
|
| Ruby is a language designed in the following steps:
|
| * take a simple lisp language (like one prior to CL).
| * remove macros, s-expression.
| * add simple object system (much simpler than CLOS).
| * add blocks, inspired by higher order functions.
| * add methods found in Smalltalk.
| * add functionality found in Perl (in OO way).
|
| So, Ruby was a Lisp originally, in theory.
| Let's call it MatzLisp from now on. ;-)
|
| matz.
|=========================================================================
| (Yukihiro Matsumoto aka matz is the creator of Ruby).

--
__Pascal Bourguignon__