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 ~ [EMAIL PROTECTED]
http://www.jaedworks.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
