Comparing Classes with Case ?

[Warren Seltzer]

------=_NextPart_000_00A3_01C5D983.FB188B00
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit

The following failure surprised me:

Version 1:

irb(main):068:0> "hi".class == "hi".class
=> true
irb(main):069:0> "hi".class === "hi".class
=> false


Version 2:

irb(main):055:0> case "whatever".class
irb(main):056:1> when String
irb(main):057:1> p "it is a string"
irb(main):058:1> else
irb(main):059:1* p "it is not a string"
irb(main):060:1> end
"it is not a string"

What it amounts to is you can't use case/when to test for class. This is a HUGE LOSE.
The pickaxe book .chm says YOU CAN do it. I'm using ruby 1.8.2

Warren


------=_NextPart_000_00A3_01C5D983.FB188B00--

 

[Robert Klemme]

The following failure surprised me:

Version 1:

irb(main):068:0> "hi".class == "hi".class
=> true
irb(main):069:0> "hi".class === "hi".class
=> false


Version 2:

irb(main):055:0> case "whatever".class
irb(main):056:1> when String
irb(main):057:1> p "it is a string"
irb(main):058:1> else
irb(main):059:1* p "it is not a string"
irb(main):060:1> end
"it is not a string"

What it amounts to is you can't use case/when to test for class.
This is a HUGE LOSE. The pickaxe book .chm says YOU CAN do it. I'm
using ruby 1.8.2

You're using it wrong:
"is string"
=> nil

Kind regards

robert

 

[Christophe Grandsire]

The following failure surprised me:

Version 1:

irb(main):068:0> "hi".class =3D=3D "hi".class
=3D> true
irb(main):069:0> "hi".class =3D=3D=3D "hi".class
=3D> false


Version 2:

irb(main):055:0> case "whatever".class
irb(main):056:1> when String
irb(main):057:1> p "it is a string"
irb(main):058:1> else
irb(main):059:1* p "it is not a string"
irb(main):060:1> end
"it is not a string"

What it amounts to is you can't use case/when to test for class. This = is a
HUGE LOSE.
The pickaxe book .chm says YOU CAN do it. I'm using ruby 1.8.2

Lose the ".class". =3D=3D=3D automatically looks for the class of the lef=
t argument.
In your case example, just write:
case "whatever"
when String
p "it is a string"
else
p "it is not a string"
end

It's work like a charm. Basically "a =3D=3D=3D SomeClass" is the same as =
"a.class =3D=3D
SomeClass".
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Robert Klemme]

En réponse à Jacob Fugal :

You're right of course! I keep forgetting that order .


It makes sense, but I still have difficulties remembering it .


Yes, and although the order makes sense, from a functional point of
view, it is difficult to get my head around the idea that case
indicates the argument rather than the receiver.

If you think about it for a moment you'll see that it's the only
reasonable approach: the expression after the case is the item to test and
all expressions after when denomiate conditions. You can for example do
this, which might make it clearer...

def Condition(&b)
class <<b
alias === []
end
b
end

case a_number
when Condition {|x| x < 10}
...
end

Of course, you can have this easier as in

case
when a_number < 10
...
end

But for more complicated conditions you might want to assign it to a const
so you can reuse it efficiently.

Kind regards

robert

 

[Christophe Grandsire]

If you think about it for a moment you'll see that it's the only
reasonable approach: the expression after the case is the item to test = and
all expressions after when denomiate conditions.

Of course it is the only reasonable approach. I agree completely with it.=
But it
doesn't change that the order in which the case and the when parts read k=
ind of
imply a left-to-right, rather than right-to-left, relationship, especiall=
y
since in other languages I know with a case/switch expression it's exactl=
y what
happen under the hood .

So although I see why it *should* be the way it is in Ruby, I still can't
remember it reliably. It's not a Ruby problem, it's a me problem .

You can for example do

this, which might make it clearer...

def Condition(&b)
class <<b
alias =3D=3D=3D []
end
b
end

Wow! Some of the things one can do with Ruby make my head spin! The worst=
is: I
can understand what it means!!!

case a_number
when Condition {|x| x < 10}
...
end

Cool trick indeed . But I'll just try to remember the order from now o=
n, or
at least remember how to get back to it...
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Robert Klemme]

Of course it is the only reasonable approach. I agree completely with
it. But it doesn't change that the order in which the case and the
when parts read kind of imply a left-to-right, rather than
right-to-left, relationship, especially since in other languages I
know with a case/switch expression it's exactly what happen under the
hood .

Just out of curiosity: which languages are you referring to and what do
they do?

So although I see why it *should* be the way it is in Ruby, I still
can't remember it reliably. It's not a Ruby problem, it's a me
problem .

You can for example do

this, which might make it clearer...

def Condition(&b)
class <<b
alias === []
end
b
end

Wow! Some of the things one can do with Ruby make my head spin! The
worst is: I can understand what it means!!!

Pity you... )

Cool trick indeed . But I'll just try to remember the order from
now on, or at least remember how to get back to it...

Ok, print this out in a bold 64pt font "I must never forget that in a CASE
statement conditions have their === invoked."

Kind regards

robert

 

[Christophe Grandsire]

Just out of curiosity: which languages are you referring to and what do
they do?

The only languages I've ever used that I know have a switch/case statemen=
t are
Pascal, C and LINC (a database-related language from Unisys). AFAIK, in a=
ll
those cases the case statements are equivalent to using an if/elsif/else
construction, with the expression introduced by the switch/case being at =
the
*left* of the equal sign, and the different possibilities at the right. I=
t is
especially true of LINC, where the case statement can only introduce a
variable, while the different choices can be literals (and literals in LI=
NC
can't be at the left of a condition expression).

Pity you... )

When I see this kind of programs, I always think: there's just no way I s=
hould
be able to understand this! I am whether completely wrong in my understan=
ding,
or getting insane! (you have to realise I've never had true IT or CS educ=
ation
in my entire life)

Ok, print this out in a bold 64pt font "I must never forget that in a C= ASE
statement conditions have their =3D=3D=3D invoked."

It will get lost in the moving (I'm moving within a month). But I'll keep=
this
post, for security .

Thanks!
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Robert Klemme]

The only languages I've ever used that I know have a switch/case
statement are Pascal, C and LINC (a database-related language from
Unisys). AFAIK, in all those cases the case statements are equivalent
to using an if/elsif/else construction, with the expression
introduced by the switch/case being at the *left* of the equal sign,
and the different possibilities at the right. It is especially true
of LINC, where the case statement can only introduce a variable,
while the different choices can be literals (and literals in LINC
can't be at the left of a condition expression).

Interesting to learn. Note however, that - if my rusty PASCAL doesn't
fool me - for PASCAL and C only scalar types are allowed for cases and
equality is commutative for these. So the convention having the var at
the left side in the if/else cascade may only because it reads more
natural for humans but it may actually have no meaning with respect to
language implementation (and it doesn't even change the semantics in these
cases). Note also that the if/else can become quite complex for C because
of fallthrough.

I don't know LINC but from what you say it sounds as if it's actually
different there.

When I see this kind of programs, I always think: there's just no way
I should be able to understand this! I am whether completely wrong in
my understanding, or getting insane! (you have to realise I've never
had true IT or CS education in my entire life)

Then you probably get it from Ruby... Seriously, it doesn't hurt to
read through some good books on algorithms and data structures to
understand why a Hash is more efficient than an Array in certain scenarios
etc.

It will get lost in the moving (I'm moving within a month). But I'll
keep this post, for security .

I was just going to offer to repost it... ))

Kind regards

robert