3 ms·
Not just to you but to other comments too on the 'is_a?' issue: The basic issue is that this is supposed to be a 'learn ruby' tool but rather than use the ruby
by twelvechairs 13y ago
Not just to you but to other comments too on the 'is_a?' issue:
The basic issue is that this is supposed to be a 'learn ruby' tool but rather than use the ruby class system (a fundamental thing to learn for beginners) to define what is in a Place they have used a custom non-class-based system instead. The result of this is that rather than allowing the user to choose their own way to do things (remembering that ruby is a 'there is more than one way to do things' language), it prescribes certain ways of working (or at least makes them easier than others).
I'm not saying everyone should program the way I do but I want to write a simple 'case warrior.feel; when Enemy;x; when Stairs;y; when Empty...' statement which is usually pretty clear and logical ruby but is prevented by this structure.
- stormbrew 13y agoAlthough you're right that the case statement looks a lot nicer (though ```case; when warrior.enemy?;x; when warrior.stairs?;y...``` is really not much worse if you really want a case statement), I'm going to have to join the chorus in vehemently disagreeing that testing the type is in any way idiomatic ruby. #is_a? is generally considered a code smell in Ruby. It should not matter if the object is of type Enemy, it responding to the message #enemy? is an interface that any object of any type can implement.
- Volpe 13y agoJust as a challenge, thought I'd try to make as case like statement as possible... not sure I like it... {'enemy?' => 'attack', 'captive?' => 'rescue' }.each { |test, response| self.send(response) and break if warrior.feel.send(test) }