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.
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
···
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.
In message "Re: Why do true and false have separate classes" on Wed, 14 Jan 2009 22:26:32 +0900, Ruby Rabbit <sentinel.2001@gmx.com> writes:
Having 2 separate classes really complicated things since i don't want
to define 2 separate renderers and editors for true and false.
Unlike Java, true and false are mere representative of boolean values.
false and nil are treated as false value, and everyhing else are true
value. So just moving true and false under Boolean does not solve the
problem, I think.
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-forum.com/\.
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.
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.
···
On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com> wrote:
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.
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.
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?
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.
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.
···
On Wed, 14 Jan 2009, Pascal J. Bourguignon wrote:
On Wed, Jan 14, 2009 at 8:26 AM, Ruby Rabbit <sentinel.2001@gmx.com> wrote:
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.
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.
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 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"?
Both are true.
Wrong. Neither is true. That is, each is either false or nil.
Understand?
Acolytes of Commune Lisp are incapable of comprehending any language
that isn't as ancient as COBOL, FORTRAN, LISP, or APL.
Give one of them like this one an inch, and he will erase your
hard drive:
You're not the first person, not even the first person on this list,
who scoffs at Ruby -- and that's your prerogative -- but please do not
talk about Matz as someone who has "massacred" any language.
Aside from being snide and obnoxious, the notion of a massacre is just
plain wrong. Lisp is still alive, and you can still use it.
Let's be nice.
David
···
On Thu, 15 Jan 2009, Pascal J. Bourguignon wrote:
Mike Gold <mike.gold.4433@gmail.com> writes:
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"?
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"?
Both are true.
You're not the first person, not even the first person on this list,
who scoffs at Ruby -- and that's your prerogative -- but please do not
talk about Matz as someone who has "massacred" any language.
Aside from being snide and obnoxious, the notion of a massacre is just
plain wrong. Lisp is still alive, and you can still use it.
Let's be nice.
Maybe Internet discussions such as this shouldn't be taken so seriously.
I think Matzacred is funny and obnoxious at the same time, which is why
I don't mind it. I'd rather laugh with the sinners than cry with the
saints.
If you were aiming to be a peacemaker, then you made a crucial mistake.
You did not address William James' posts, which have been at least
equally obnoxious. It appears that you are only censuring Pascal.
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"?
Both are true.
You're not the first person, not even the first person on this list,
who scoffs at Ruby -- and that's your prerogative -- but please do not
talk about Matz as someone who has "massacred" any language.
Aside from being snide and obnoxious, the notion of a massacre is just
plain wrong. Lisp is still alive, and you can still use it.
Let's be nice.
The wrong doing is in the mindshare. I agree that it is not as wrong
and bad as C++ or Java, but still.