Comment by epidemian | Hacker News Reader

Comment by epidemian | Hacker News Reader

Parent Full thread

Hehe, i feel identified with some of these frustrations, but i think it's better the way it is.

> Its more ruby style to do 'space.is_a?(Enemy)' than 'space.enemy?'. This would also help to build case statements rather than lots of ifs.

But that would require to explain that an Enemy class/module (and possibly others) exists. With the presented interface you can/should only care about Warrior and Place. Much simpler.

> no 'print' or 'puts'. How am I supposed to know what 'look' returns when it never really tells me?

With Ruby's Array methods. Warrior#look returns an Array of at most 3 Places. What else should you know?

> I prefer a single set of rules rather than adding rules as you go. When first I have to use :backward but later this becomes basically redundant as 'pivot' is added, it just makes me frustrated in having to refactor. Same thing for feel/look.

That happened to me too, but i think it adds to the sense of progress and discovery throughout the game. Like most games, you don't start with all the tools and abilities at your disposal. And you can always ask respond_to? if you want an algorithm that works for all level ;)

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.

Just 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) }

Although 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.

Reply on news.ycombinator.com