If you want to make a long story short, go directly to the end of this
message and read a complete proposal, then you can go back and read
individual comments to your points.
entropyreduction wrote:
> Plugin just receives
> one string, assumes within that string the usual thing (white space
> delimits args, commas don't matter). User either passes in
> all args or one, depending on how he wants to use i.e. he may wish to
> parse everything in just the first ppro arg, or contents of all the
> ppro args.
>
agreed.
>>
>> Yes, but how do return values? Possibly in a simple way? I still
> like
>> the Perlish way better, assuming that it's technically feasible in
>> PowerPro.
>
> That's easy. You pass in the name of a variable, either as part of a
> map or part of a string. plugin sets that variable (which
> unfortunately has to be global, ASAIK). So after call to plugin, the
> variables you specified are set (if it's a flag, probaby set the
> specified var with 0/1).
>
I don't understand your answer. You wrote "you pass in the name of a
variable as [...] a map". Isn't this exactly what I wrote in a previous
message? How is it different? I wrote before:
local error = Options.syntax(opts, syntax, args)
where opts is the name of a map, syntax is a string holding the parsing
rules, and args is a string holding the arguments to parse.
>
> Meanwhile decided better (to avoid race conditions between several
> scripts trying to use plugin at same instant) to _not_ have time gap
> between time you set the parsing rules and time you get result.
> Better to do as you originally suggested and have just one plugin
> service,
>
> options.eval(<the rules in some form>,<the arguments to parse>)
makes sense.
Apart from renaming options.syntax to options.eval in my previous
proposal, the different element is the lack of the opts map name. How
does options.eval return parsed values?
>> > Or the plugin raises a script error dialog if the syntax is wrong?
>> >
>>
>> I hate when PP or plugins raise error dialogs. I want to be able to
>> control the user interface of my scripts.
>
> That'sokay, my standard plugin form has a service to turn error
> dialogs on and off.
>
Best of two worlds, I like that!
>> > Or options.go(theArgsToParse)
>> > options.getParsedArg(index)
>> >
>>
>> Your options.go() is the same as my options.syntax() right?
>
> Yup. But now I prefer all-in-one-go service, because of race
> condition problem.
>
If you're saying,
options.eval(<the rules in some form>,<the arguments to parse>)
options.getParsedArg(index)
isn't there a potential race condition between eval and getparsedarg?
One way to fully avoid race conditions is to define one single call:
options.parse(<the rules in some form>,<the arguments to parse>,<pointer
to variable space used to return parsed values>
which is equivalent to options.syntax() above.
>
> There are lots of properties to specify for each possible parameter:
Let me give you my own preference. I think your C++ classes are
incredibly powerful, yet in my everyday experience I would be fully
satisfied with something less powerful.
>
> short form
Must have.
> long form
Must have.
> is it optional
Not needed, as long as the plugin doesn't raise an error if it doesn't
find a parameter. In other words, ALL parameters are optional, then it's
the script that complains if a mandatory parameters wasn't specified:
; pseudocode
if( undefined(<name of var holding the parsed value>) )do
messagebox("error", "what? that parameter is mandatory!")
messagebox("ok", <usage string>)
endif
> how many arguments follow it (0/1, maybe more than 1?)
Just one. That's enough for me.
> if you allow only one argument, what's it type?
They're all strings anyways. The script could check returned values
using the various miscplugin.isTYPE() services. OTOH, it wouldn't be too
difficult to define a way to specify the argument type:
x:xlongform:: means -x || -xlongform
x:xlongform:i: means -x <integer> || -xlongform <integer>
x:xlong:i;y:ylong:s:z:zlong:: means
-x <int> || -xlong <int> || -y <string> || -ylong <string> || -z || -
zlong
> default value if missing
let the script deal with that. Just optionally raise error if
x:xlong:i: isn't followed by <integer>
> message to put out (via errordialog or return from serice)
> if parameter missing
x:xlong:i:x errmsg;y:ylong::y errmsg ... you get the idea
>
> Depending on what I'm allowed to do, you could do this
>
> options.eval(<vector of maps>, <string to evaluate>)
>
> There would be one map for each parameter, with
> elements "short", "long", "optional", "resultvar"....
>
> Or, this:
>
> options.eval(<vector of short names>,
> <vector of long names>,
> <vector of ppro var names>,
> <vector of "is it optional" flags>,
> <vector of default values>,
> <string to evaluate>)
>
>
So, summarizing and factoring in all our ideas, I propose the following
service and syntax:
error_message = options.eval(<option syntax>,<arguments>)
// option.eval returns a properly formatted error message
// (whose parts are specified in the <option syntax>) if a
// parsing error was encountered, otherwise it returns "".
// Optionally the plugin can be configured to automatically
// raise an error message box.
usage_message = options.usage(<option syntax>)
// option.usage returns a properly formatted usage message
// (whose parts are specified in the <option syntax>). This
// is the complete usage message, not just an error message.
// No parsing is involved here.
// Option Definition Syntax
<option syntax> ::= <option> [ ';' <option> ]*
<option> ::= <output name>:<short>':'<long>':'<type>':'<usage msg>
<output name> ::= <PowerPro expression> // see comments below
// any PP expression that evaluates to the name of a global variable
// INCLUDING the name of a map element, i.e., m["x"]
<short> ::= <single letter> // can't be ':' or ';'
<long> ::= <string> // can't include ':' or ';'
<type> :: 'i' | 's' | 'b' //possibly others except ':' or ';'
// integer, string, boolean, ...
<usage msg> ::= <string> // can't include ':' or ';'
// keep the <option syntax> string as short as possible, PPro has string
length limits
Example:
global opt = map.create(2)
opt["x"] = "undefined"
opt["y"] = "undefined"
local rules
; all on one line below
setstring rules opt["x"]:x:xlong:i:-x|-xlong <integer>;opt
["y"]:y:ylong::-y|-ylong
; all on one line above
local demo = "-xlong 3" ;; demo string
local message = options.eval(rules, demo)
; assume the plugin is set NOT to raise an error message box
if ( message ) do
messagebox("error", message)
quit(-1)
endif
; all options parsed
if ( "undefined" == opt["y"] )do
; that's OK, I meant -y to be optional anyway
endif
if ( "undefined" == opt["x"] )do
messagebox("error", "sorry, -x is a mandatory option.")
messagebox("ok", options.usage(rules)) ;; whole usage msg
quit(-2)
endif
; now opts["x"] is guaranteed to be an interger
if( 14 != 1 + opts["x"] )do
messagebox( "error", "can't be, demo string was: -x 13" )
endif
--sgp
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/JV_rlB/TM
---------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/power-pro/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
