From: E S <eero.saynatkari@...>
Date: 2004-12-31T06:40:45+09:00
Subject: [OT]:Re: Text adventures (was: Re: #send and private methods)

> L�hett�j�: Brian Palmer <brian@pocketmartiansoftware.com>
> P�iv�ys: 2004/12/29 ke PM 05:52:53 GMT+02:00
> Vastaanottaja: ruby-talk@ruby-lang.org (ruby-talk ML)
> Aihe: Re: #send and private methods
> 
> I certainly see what you mean--I can think of cases where it would be 
> useful to bypass the private status of a method, as well.  I was curious 
> how others felt, though.  The reason I ran across the #send behavior is 
> this--I've been toying with different ways of writing a Infocom-style 
> text adventure interpreter in Ruby, and one idea I had was a 'command' 
> object or module that would contain a bunch of methods named after 
> verbs, such as 'look' and 'west'.  Then I would just have the 
> interpreter do a #send with whatever the user typed in, and let 
> #method_missing handle the "I don't understand what you mean" type 
> messages.  I was just a bit shocked when I discovered that typing 'gets' 
> into my interpreter actually called the private method 'gets' (and I 
> started thinking about what the adventurous adventurer could do with a 
> well-designed #instance_eval command :)
> 
> But of course, this is easily avoided by checking whether #send would 
> call a public method, or using the awesome "evil ruby" to make a class 
> without Object and Kernel methods.  Not to mention that, while an 
> interesting idea, it's not necessarily the most elegant way to do things 
> anyway.

I--and surely others on this group--am working with MUDs (text-based 
MMORPG predecessors for those not in the know). There're several 
command interpretation options around, a Trie (a ternary tree of 
sorts) being probably the fastest for Ruby (due to lack of pointer 
manipulation). I've also got a class that implements a partial hash 
(allows 'hel' or 'hlep' to match 'help') while still reasonably fast. I can send you some code if you want to take a look at it.

E