Hi,
--- In [EMAIL PROTECTED], sgp <[EMAIL PROTECTED]> wrote:
> I thought about this some more, and if your C++ classes already
support
> this, then the plugin should implement it.
> Add syntax ':' <optional> ':' where <optional> ::= '0'|'1'
Ok.
Then default value too?
> >> > how many arguments follow it (0/1, maybe more than 1?)
> >> Just one. That's enough for me.
> zero or one.
If it's a flag, then no args (no point in following --flag with 1 or
0): if it's string or int, one arg.
> >> > if you allow only one argument, what's it type?
> >> x:xlong:i;y:ylong:s:z:zlong:: means
> >> -x <int> || -xlong <int> || -y <string> || -ylong <string> || -
z
> >|| -zlong
> >
> > Shall we keep it simple and drip type-checking within plugin then?
> >
> Plugin does type checking, at least :i: for integer, what else is
really
> needed?
For now string and int handled the same, but will add int checking
eventually.
> >> 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.
> >
> > actually I was thinking of returning "OK: n" where n was the
number
> > of parameters found.
> >
> What's the use of n?
> I think the error message is more useful. Note that this error
message
> is not the whole usage message, it includes just the <usage msg>
fields
> of the options that didn't parse correctly. This makes it easy to
focus
> the user's attention on just the syntax errors that he actually
made.
Oh, okay, thats what you had in mind for <usage msg>. Fine.
<usage msg> is optional, yeah?
> >> 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>
>
> Adding <optional> this now becomes
> <option> ::= <output name>
> ':' <optional>
> ':' <short>
> ':' <long>
> ':' <type>
> ':' <usage msg>
> <optional> ::= '0' | '1'
>
> >> <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
>
> Here we go, stealing the idea from the keymap plugin, I'd like to
> propose to use an external file to specify the option syntax,
instead of
> a string. I can see several advantages:
> 1. overcome string length limitations--modified syntax: one
<option> per
> line
> 2. easy to prototype and change
> 3. no need to change the script itself--great when one didn't
author the
> script
> 4. easy to localize usage messages in another language--important,
since
> options parsing is part of the user interface
One line per option?
Or ini file-like 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.
> >
> > actually I was thinking of returning "OK: n" where n was the
number
> > of parameters found.
> >
> What's the use of n? I think the error message is more useful. Note
that
> this error message is not the whole usage message, it includes just
the
> <usage msg> fields of the options that didn't parse correctly. This
> makes it easy to focus the user's attention on just the errors that
the
> user made when keying in a long list of options.
Yeah, you get ERROR: blah blah if something goes wrong, OK: n or
maybe just n if no error (n being number of args successfully parsed).
> >> 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>
>
> Adding <optional> this now becomes
> <option> ::= <output name>
> ':' <optional>
> ':' <short>
> ':' <long>
> ':' <type>
> ':' <usage msg>
> <optional> ::= '0' | '1'
<optional> , <type>, <usage msg> optional? If so need to go at end.
> >> <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"]
Can be anthing local or global, including map element, vector element.
Of course map, vector or var have to be previously declared.
> >> <short> ::= <single letter> // can't be ':' or ';'
Not enforcing that. Can do. Tradition is it's a single char, but
why e.g. not two?
> >> <long> ::= <string> // can't include ':' or ';'
> >> <type> :: 'i' | 's' | 'b' //possibly others except ':' or ';'
> >> // integer, string, boolean, ...
I just check the first letter of what ever you put in type slot:
b, i,s,f (for flag).....
> >> <usage msg> ::= <string> // can't include ':' or ';'
> >>
> >> // keep the <option syntax> string as short as possible, PPro
has
> > string
> >> length limits
>
> Here we go, stealing the idea from the keymap plugin, I'd like to
> propose to use an external file to specify the option syntax,
instead of
> a string. I can see several advantages:
> 1. overcome string length limitations--modified syntax: one
<option> per
> line
> 2. easy to prototype and change
> 3. no need to change the script itself--great when one didn't
author the
> script
> 4. easy to localize usage messages in another language--important,
since
> options parsing is part of the user interface
> Revised Sample Script
> =====================
> ; define option syntax
> global opt = map.create(2)
> local r1 r2
> setstring r1 opt["x"]:0:x:xlong:i:mandatory -x|-xlong followed by
<int>
> setstring r1 opt["y"]:1:y:ylong::optional -y|-ylong
>
> ; create options file if it doesn't already exist
> local rulefile=scriptfolder++"\"++scriptname++".opt"
> local nl
> setstring nl 'r
> if( not validpath rulefile )
> file.writeall(rulefile,r1++nl++r2)
>
> ; test the plugin
> local test = "-xlong 3"
> local message = options.eval(rulefile, test)
>
> ; assume the plugin is set NOT to raise an error message box
> if ( message ) do
> messagebox("error", message)
> quit(-1)
> endif
>
> win.debug("parsed -x=3 and no -y (optional). Check:",opt["x"],opt
["y"])
> quit(0)
I think those gotta be alternatives. For very simple syntax
eval(syntaxString,...), for more complex ones
eval(syntaxVector,...),
eval(syntaxFile,...)? May have to have two different services, or
maybe I can check first arg to see if it's a file.
> Revised Service definition
> ==========================
> error_message = options.eval(<syntax file>,<arguments>)
> // Option.eval parses <arguments> and sets return values
> // according to an <option syntax> specified in a <syntax file>
> // It returns "" if no syntax error occurred.
> // It returns a properly formatted error message
> // (whose parts are specified in the <option syntax> when
> // one or parsing errors are found.
> // Optionally the plugin can be configured to automatically
> // raise an error message box.
>
> usage_message = options.usage(<syntax file>)
> // Option.usage returns a properly formatted usage message
> // (whose parts are specified in a <syntax file> according
> // to an <option syntax>. This is the complete usage message,
> // as if all possible parsing errors were encountered. However,
> // no actual parsing takes place.
>
> Revised Option Definition Syntax
> ================================
> <option syntax> ::= <option> [ ';' <option> ]*
> <option> ::= <output name>
> ':' <optional>
> ':' <short>
> ':' <long>
> ':' <type>
> ':' <usage msg>
> [ ':' <reserved> ':' <reserved> ':' <reserved> ':'
<comments> ]
>
> <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"]
> <optional> ::= '0' | '1' // flag
> <short> ::= <single letter> // can't be ':' or ';'
> <long> ::= <string> // can't include ':' or ';'
> <type> :: 'i' //possibly others except ':' or ';'
> // i=integer
> <usage msg> ::= <string> // can't include ':' or ';'
> <reserved> ::= NULL // reserved for future use
> <comments> ::= ANY STRING // user comments
>
> Complicated for the novice script writer who is forced to learn
vectors
> of maps just to say .Script("-x 1"). Sorry.
> Also, I think the external syntax file is a more flexible approach,
the
> keytrap plugin is a living example.
Haven't used it.
> I understand you'd prefer to not parse strings, but basically the
above
> syntax can be parsed by simply breaking a line at ':' field
dividers.
Yeah, okay, will think about it.
> > BTW you willing to act as documentation editor and tester for
this
> > thing?
> >
>
> Yes, but honestly if it's kept simple for the user, and your last
> proposal seems complicated.
What format for file then?
I prefer to conduct this thread by e-mail.
In any case I have a rough cut of the plugin I can send you if you
want to play with it.
Haven't tested the vector-of-strings syntax, only the vector-of-maps.
Artifical restrictions: short code < 10 chars, long < 50, return var
< 50, usage < 100. I'll probably knock out the restrictions later.
At moment only one data value allowed after an option.
Possible types are flag, bool (same thing) string, int (treated the
same for now: the first two just present or absent, the latter two
require a following value.
Possible error messages:
-- syntax: vector has 0 elements (or empty syntax sting or file)
-- syntax: vector element neither map nor non-null string
-- syntax: short, long, retvar fields missing for an option
-- syntax: int/string field missing following data
-- string: to parse has no fields (is that an error?)
------------------------ 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/
