- not being able to see the class of something. 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.
- no 'print' or 'puts'. How am I supposed to know what 'look' returns when it never really tells me?
- 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.
I don't feel `.is_a?(Class)` is ever idiomatic ruby. You should always be coding to an interface, not an implementation. This prevents things like mocks and duck typing, making testing more difficult and adding complexity when you want to add AnotherEnemy that doesn't share the same inheritance tree.
I try to avoid using `.is_a?(Class)` in all of my ruby code when possible. `.respond_to?` is much more responsible way of probing whether an object has the interface you are looking for.
> I try to avoid using `.is_a?(Class)` in all of my ruby code when possible. `.respond_to?` is much more responsible way of probing whether an object has the interface you are looking for.
#is_a?(class) is a much more specific check of semantics than #respond_to?(method_name). is_a? is the more cautious approach (least likely to produce false positives at the expense of being most likely to produce false negatives) whereas respond_to? is the less cautious approach (least likely to produce false negatives while most likely to produce false positives.)
I am well aware of duck typing, and rarely use either #is_a? or #respond_to?
That doesn't change that, if you have a reason to use that type of inquiry to check interfaces, #is_a? is the more safe of the two (more likely to reject an object that provides the semantics of concern and less likely to accept one that does not) and #respond_to? is the less safe (more likely to accept an object that does not provide the semantics of concern and less likely to reject one that does.)
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.
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.
- Not sure why they chose to disallow them here, but realistically #while loops are not commonly used in Ruby. Iterators such as #each or #map are far more idiomatic for Ruby. I still agree this is strange that they are not included here. The original allows all of Ruby https://github.com/ryanb/ruby-warrior
- Obfuscating the class is intentional... you are being given a limited set of "sensors" with which to interact with the world. Those are intentional rules by which to play the game.
- The original game is plain old Ruby run in the terminal and has full access to #puts or #print
- I think the point is to increase the complexity of the api slowly for those new to ruby and or programming in general. Not to beat a dead horse, but in the original there is the notion of epic mode where you do have access to all the rules and can attempt to run the entire tower with the same code.
No loops because (as it's a game AI) it's meant to be called once per game tick, rather than as a driver. I didn't try continuations but it's possible you could get something like that to work.
As a Rubyist for a decade now, please avoid is_a? if at all possible. It defeats the awesome flexibility that is duck typing. Also, I have no idea why you feel that would be better for cases, my code ran in a case statement for brevity.
'look' told me that it returns an array of Spaces. They're the same type as the Space feel returns.
- while, until, retry (and others?) not allowed.
- not being able to see the class of something. 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.
- no 'print' or 'puts'. How am I supposed to know what 'look' returns when it never really tells me?
- 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.