Why isn't Rev more popular?

[Jeanne A. E. DeVoto]

At 1:06 PM -0500 12/2/2005, Bill Marriott wrote:
>Well for reasons I may not be aware of, all the new commands seem to 
>be in the format, "revDoSomething" followed by parameters. Example:
>
>     revAddXMLNode treeID, parentPath, nodeName, nodeContents
>
>Why couldn't you say something like
>
>     add node "Balls" to the root path of XML tree id 9

Partly this is for historical reasons, partly practical ones, and 
partly because the syntax for custom commands and functions isn't 
very flexible.

These types of commands are in libraries. Instead of being built into 
the engine, they're implemented as script libraries (or as externals 
- which have the same calling syntax). The problem is that when you 
create a command with a handler, you're limited to a comma-delimited 
set of parameters:

   on doSomething thisParam,thatParam,theOtherParam
     -- code here
   end doSomething

And you call the above with a line like:

   doSomething 2,"fox",the short name of me

This syntax limitation applies to all commands and functions that 
aren't actually built in.

(Why, you ask, aren't things like the XML and database commands built 
in? There are two reasons.

The historical reason is that RunRev did not originally own or 
control the MetaCard engine, so if RunRev wanted some feature that 
Scott Raney didn't want to put into the engine, it had to be 
implemented as a library. Since RunRev now owns the MetaCard engine, 
that's no longer a problem, but most of the libraries were added 
before that change in ownership. That's also the reason that the 
library commands and functions are all prefixed with "rev-".

he practical reason is that it's easier to tweak a library than the 
engine, so if a library's features are rapidly shifting, it makes 
more sense to keep it out of the engine. Also, there is the issue of 
space - if that code were added to the engine, it would cause some 
degree of bloat, while leaving a library out of a standalone is easy. 
You'll notice most of the libraries cover functionality that not all 
apps need, so leaving them in separate libraries is a way of getting 
some modularity.)



Personally, I think the root cause of the problem is the inflexible 
syntax for non-built-in commands and functions. What I'd like to see 
is the ability to separate parameters with spaces as well as commas, 
so you could do something like:

   on doSomething thisParam,null1,null2,thatParam,null3,null4,theOtherParam
     -- code here
   end doSomething

called with:
   doSomething 2 times to "fox" in stack (the short name of me)

The comma-delimited syntax is fine for single-parameter and 
zero-parameter functions and commands, but with more parameters you 
need a little syntactic sugar. Particularly in libraries that many 
programmers use. If something like this were permitted, we could have 
complex commands in separate libraries or externals without their 
being quite so ugly.
-- 
jeanne a. e. devoto ~ revolution at jaedworks.com
http://www.jaedworks.com