From: ggarramuno@... (GGarramuno)
Date: 2004-03-17T02:14:38+09:00
Subject: Re: Embedding Ruby, part 2


Joe Mason <joe@notcharles.ca> wrote in message:
>
>> I like the syntax "MEL.ls -type b", but that might mess up the
>> cut-and-pasting you mentioned.

Me too, but the -type afaik cannot be parsed appropiately, right?
Also, as you mentioned, running MEL commands that have equivalent in ruby would
be an issue (not a big one, really, but still...).



Well, what I did eventually was this:

I provided Object.toMEL() which like to_s() returns a string object, with the
object turned into MEL syntax for each of the basic ruby types.

I left a MEL() command supporting one or multiple parameters.  The first
parameter is just sent as is, while the others are parsed based on type,
calling toMEL() appropiately.

This allows writing:

MEL("ls -type time")

MEL(<<"EOF")
ls -type time:
select -r time;
EOF

objtype = "time"
MEL("ls -type ", objtype)

objtype = "time"
MEL(<<"EOF")
ls -type #{objtype.toMEL}:
select -r #{objtype.toMEL};
EOF

I think some of my objections remain, but I think this is the best compromise
so far.
This still allows the user to cut/paste code (he just has to go thru the pain
to put it it in an << block or MEL()).
This also allows you to write MEL code with conflicting commands to ruby (ie.
for, etc).  It also makes it obvious which variables are MEL variables and
which are ruby ones.

Not a perfect solution but not much to ask users to remember, I guess.

Now if I could only get FOX to exit properly, I think we would have a real
winner here.