«

I'm used to thinking of === being MORE useful
On thinking about it, I can see why: in A === A, A is of class Class,
and that class is not derived from the class A, so comparison is
false...

But this causes me some trouble, because there is no way to use
case statements with a class:

class A
Ordinal = 1
end
class B
Ordinal = 2
end

t = A

case t
when A then ...
when B then ...
end

No case will ever match!

Is my only way:

if t == A
...
elsif t == B
...
elsif
.....

or is there some clever workaround?

I thought of

t = A

case t.new
when A then ...


But in my case, A and B actually have initialize methods, and they
require args (different args).


Thanks,
Sam

--
Sam Roberts <>

On 01:24 Thu 24 Feb , Sam Roberts wrote:
> I'm used to thinking of === being MORE useful
> On thinking about it, I can see why: in A === A, A is of class Class,
> and that class is not derived from the class A, so comparison is
> false...
>
> But this causes me some trouble, because there is no way to use
> case statements with a class:
>
> class A
> Ordinal = 1
> end
> class B
> Ordinal = 2
> end
>
> t = A
>
> case t
> when A then ...
> when B then ...
> end
>
> No case will ever match!
>
> Is my only way:
>
> if t == A
> ...
> elsif t == B
> ...
> elsif
> .....
>
> or is there some clever workaround?

You could do:

case t.name
when "A" then ...
when "B" then ...
end

or

case t.id
when A.id then ...
when B.id then ...
end

Still kind of kludgy, though.

- Jamis

--
Jamis Buck

http://jamis.jamisbuck.org
------------------------------
"I am Victor of Borge. You will be assimil-nine-ed."

"Sam Roberts" <> schrieb im Newsbeitrag
news:...
> I'm used to thinking of === being MORE useful
> On thinking about it, I can see why: in A === A, A is of class Class,
> and that class is not derived from the class A, so comparison is
> false...
>
> But this causes me some trouble, because there is no way to use
> case statements with a class:
>
> class A
> Ordinal = 1
> end
> class B
> Ordinal = 2
> end
>
> t = A
>
> case t
> when A then ...
> when B then ...
> end
>
> No case will ever match!
>
> Is my only way:
>
> if t == A
> ...
> elsif t == B
> ...
> elsif
> .....
>
> or is there some clever workaround?
>
> I thought of
>
> t = A
>
> case t.new
> when A then ...
>
>
> But in my case, A and B actually have initialize methods, and they
> require args (different args).

Nah, this is better (define a criterion):

>> class A;end
=> nil
>> classA = Object.new
=> #<Object:0x1018a900>
>> def classA.===(x) x == A end
=> nil
>> case A
>> when classA
>> puts "yes"
>> end
yes
=> nil

Of course you could encapsulate all this in a class.

Kind regards

robert

Jamis Buck said:
> On 01:24 Thu 24 Feb , Sam Roberts wrote:
>> Is my only way:
[... code elided ...]
>> or is there some clever workaround?
>
> You could do:
>
> case t.name
> when "A" then ...
> when "B" then ...
> end
>
> or
>
> case t.id
> when A.id then ...
> when B.id then ...
> end
>
> Still kind of kludgy, though.

You could do ...

class A
def do_something() ... end
end
class B
def do_something() ... end
end

t.do_something

--
-- Jim Weirich http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

On Thu, 24 Feb 2005 02:38:35 +0900, Jim Weirich <> wrote:
>
> Jamis Buck said:
> > On 01:24 Thu 24 Feb , Sam Roberts wrote:
> >> Is my only way:
> [... code elided ...]
> >> or is there some clever workaround?
> >
> > You could do:
> >
> > case t.name
> > when "A" then ...
> > when "B" then ...
> > end
> >
> > or
> >
> > case t.id
> > when A.id then ...
> > when B.id then ...
> > end
> >
> > Still kind of kludgy, though.
>
> You could do ...
>
> class A
> def do_something() ... end
> end
> class B
> def do_something() ... end
> end
>
> t.do_something
>
Surprising, that the ruby way comes up at last. Quack

--
Brian Schröder
http://ruby.brian-schroeder.de/

On Wed, 23 Feb 2005 18:44:20 +0100, Brian Schröder <> wrote:
> On Thu, 24 Feb 2005 02:38:35 +0900, Jim Weirich <> wrote:
> >
> > Jamis Buck said:
> > > On 01:24 Thu 24 Feb , Sam Roberts wrote:
> > >> Is my only way:
> > [... code elided ...]
> > >> or is there some clever workaround?
> > >
> > > You could do:
> > >
> > > case t.name
> > > when "A" then ...
> > > when "B" then ...
> > > end
> > >
> > > or
> > >
> > > case t.id
> > > when A.id then ...
> > > when B.id then ...
> > > end
> > >
> > > Still kind of kludgy, though.
> >
> > You could do ...
> >
> > class A
> > def do_something() ... end
> > end
> > class B
> > def do_something() ... end
> > end
> >
> > t.do_something
> >
> Surprising, that the ruby way comes up at last. Quack

The above shall read: came up in the last message. I'm not shure if I
haven't said something completely different. Sorry that I have to
follow up my superfluous no-advice-message with another one correcting
it.

Think first, then type then think then send!

Regards,

Brian

--
Brian Schröder
http://ruby.brian-schroeder.de/

Quoting , on Thu, Feb 24, 2005 at 02:38:35AM +0900:
>
> Jamis Buck said:
> > On 01:24 Thu 24 Feb , Sam Roberts wrote:
> >> Is my only way:
> [... code elided ...]
> > case t.id
> > when A.id then ...
> > when B.id then ...
> > end
> >
> > Still kind of kludgy, though.

I think thats the best suggestion so far.

> You could do ...
>
> class A
> def do_something() ... end
> end
> class B
> def do_something() ... end
> end
>
> t.do_something

I know where you are coming from, this is a nice pattern, but in this
case t is a return value of Resolv:NS::Message#question, and I have to
answer the question. How I answer the question depends on the question
(of course!), but is not part of the behaviour of the question,
different "answers" answer the question in different ways.

Thanks for all the suggestions, folks.

Sam

Hi,

Am Donnerstag, 24. Feb 2005, 11:58:09 +0900 schrieb Sam Roberts:
> Quoting , on Thu, Feb 24, 2005 at 02:38:35AM +0900:
> > You could do ...
> >
> > class A
> > def do_something() ... end
> > end
> > class B
> > def do_something() ... end
> > end
> >
> > t.do_something

Of course.

> I know where you are coming from, this is a nice pattern, but in this
> case t is a return value of Resolv:NS::Message#question, and I have to
> answer the question. How I answer the question depends on the question
> (of course!), but is not part of the behaviour of the question,
> different "answers" answer the question in different ways.

I accept that. So I try:

$ ruby -e 'class Class ; def === oth ; self == oth ; end ; end ;
> class C ; end ; p C === C'
true

But this one crashes:

$ irb
irb(main):001:0> class Class ; def === oth ; self == oth ; end ; end
=> nil
irb(main):002:0> class C ; end
/usr/local/lib/ruby/1.9/irb/ruby-token.rb:101:in `Token': undefined method `ancestors' for ";":String (NoMethodError)
...

Is this the behaviour to be expected?

Bertram


--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

Bertram Scharpf <> wrote:
>
> $ ruby -e 'class Class ; def === oth ; self == oth ; end ; end ;
> > class C ; end ; p C === C'
> true

Not sure about the crash, but this is probably more useful behaviour:

class Class
alias :=== :caseeq

def ===(other)
(self == other) || self.caseeq(other)
end
end

martin

On Wednesday 23 February 2005 09:58 pm, Sam Roberts wrote:
> > You could do ...
> >
> > class A
> > def do_something() ... end
> > end
> > class B
> > def do_something() ... end
> > end
> >
> > t.do_something
>
> I know where you are coming from, this is a nice pattern, but in this
> case t is a return value of Resolv:NS::Message#question, and I have to
> answer the question. How I answer the question depends on the question
> (of course!), but is not part of the behaviour of the question,
> different "answers" answer the question in different ways.

I'm not sure if you are saying that won't work because (1) the do_something
method is not part of the behavior of the classes in question, or (2) you
need to respond differently to these classes in different circumstances. Or
perhaps both (1) and (2) are the case.

If (1), then remember that you can always open up any class and add more
behavior.

If (2), then you can do something like the following (simple visitor pattern):

module Kernel
def accept_visitor(visitor)
visitor.send("visit_" + self.class.name.downcase.gsub(/::/, '_'), self)
end
end

class A; end
class B; end

class MySpecialVisitor
def visit_a(a)
puts "Doing something with A: (#{a})"
end
def visit_b(b)
puts "Doing something else with B: (#{b})"
end
end

A.new.accept_visitor(MySpecialVisitor.new)
B.new.accept_visitor(MySpecialVisitor.new)

You can define as many visitors as you need to get the varied behaviors
required by your problem.

The solution is a bit more complicated, but allows open-ended behaviors for
any class.

--
-- Jim Weirich http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)