switch engine.engineTypeThe correct way to do it is this:
case: "hyperdrive" {write("You hear a whooshing sound");}
case: "warpdrive" {write("You hear a loud whine which steadily rises in pitch");}
case: "spacetimevortexdrive" {write("You hear a strange wheezing/groaning sound");}
case: "chemicalrocket" {write("There is a roar as the engines fire");}
default: {write("You hear the sound of the engines powering up";}
end
write(engine.engineType.StartUpNoise());and have each possible engine type class supply the appropriate noise via different polymorphic implementations of StartUpNoise().
o = Object.new
M = Module.new
o.extend M
o.===(Object) # true
o.===(o) # true
o.===(M) #true
case 1
when 2 then "two!"
when Integer then "number!"
end
if 2.===(1) then
"two!"
elsif Integer.===(1)
"Integer!"
end
switch( o->type )
{ case TYPE_PLAYER: do stuff; break;
case TYPE_OBJECT: do stuff; break;
default: break;
}
o->do_stuff();
Basically if you're using Ruby case statements you know it's a lot like switch/case statements in other languages.
When you examine further it doesn't use equality to test. It uses ===. Not much of a secret there, either. Because of the way it works you can do things like this:
So it matches classes as well as equality values. Interesting enough, but not all that surprising. Here's what I found surprising (because there's not much info on it) and useful.
And here's the output for those 3 iterations.
It has some pretty interesting uses since you could design methods to interact with things that mix in interfaces instead of specific objects (or even classes of objects themselves). I'm currently using this for modules in my codebase such as the Living interface to make any living things equally and consistently interface driven. This certainly beats something like:
It would be rather lame to have to maintain code as new definitions of Living things are defined.
Obligatory cutesy example follows. (DH loves em.)
And the output