From: Joe Mason <joe@...>
Date: 2004-03-16T12:21:42+09:00
Subject: Re: Embedding Ruby, part 2

In article <20040315092252.09144.00001411@mb-m14.aol.com>, GGarramuno wrote:
>>1000.times()
>>{
>>  a = ls(:type => b)
>>}
>>It would be more like standard Ruby and will certainly will be simpler
>>to do.
> 
> Sadly, it's not a good solution, for a bunch of reasons.
> MEL has over 200 commands just like "ls", all allowing multiple dash options. 
> These tend to change/be added among Maya versions, too.  The syntax above more
> or less implies I'll be parsing the options myself, which is insane work and
> kind of silly as MEL will do its own error checking for those.

FYI, you can convert symbols (like :type) to strings, so it's simple to use
the method_missing command described belore to convert the ruby
parameters ":type => b" to "-type b".  That doesn't fix your other two
objections, though.

>>module Kernel
>>    def method_missing( symbol, *args )
>>    # call the corresponding MEL function
>>    end
>>end
>>
> 
> Yes, this sounds like one of the improvements I was looking for.  Thanks!

I worry about the consequences of this.  Sounds like a huge security
hole, but I guess if you trust MEL it's not so bad.  One problem is you
can't call any MEL functions that are named the same as Ruby methods.
You'll want to keep your general MEL() function for emergencies, at
least.  (Just have method_missing convert it's args to a string and then
call MEL() to do the rest of the work.)

I like the syntax "MEL.ls -type b", but that might mess up the
cut-and-pasting you mentioned.

Joe