Forums Feature Suggestions /param - switch recognition

nifty idea here... Let's say that you make an alias and want to give it options where you could use "-n SomeonesNick -m Some message to send"

/param [-afNgsvtNuN] $1-
-a = all (everything between switches gets stored into the preceeding switch
-f = fixed switch name length (-a overrides)
-v = variable name length (-a or -f overrides)
-g = global (default is local)
-s = show variables being set
-t = token to trigger switch (58 = :, 45 = -, etc)
-u = unset in N seconds
Have that break it up where it will automatically, so the above example would return:
%n = SomeonesNick
%m = Some message to send
The -f and -v switches could provide better control, such as -f1 would make it so that "-nSomeonesNick" would do the same thing (except that "-mSome message to send" would return %m as "Some"), and -v would do the exact same as -f except that the space would be the seperator to determine what the % name is. (again, "-message Some message to send" would make %message = Some, and end at the space).

And when using -f or -v, %param would return all unused tokens, like "message to send"


Would make it easier to write scripts that can accept switches.

Seems a lot more work and a great deal more confusing than the current way to code switches, which is simply if (-* iswm $1) { process $1 as a set of switches }.

Problem there... Let's say you want to build a command that can have switches throughout the line.. (A good example would be the /server command)..

Then -* iswm $1 won't work.
What /param would(could) do is parse the line for you and seperate into variables automatically.

...And, I forgot to mention, if two switches follow one another (ie, -q -n SomeonesNick, then -q would be set to $true)..

After that 1 line, %n would have the nick, %m the message, and %q would be $true... All automatic parsing, so you just use them as you need them.

if (*-n* iswm $1-) { cmds }

switches arent hard....

But then you have to individually parse for each one, and if you have, say, 10 different options, then you have to parse each one. Unless I'm missing an obvious trick, parsing commands that can have multiple values isn't as easy as just saying "if (*-n* iswm $1-) { }" and have %n suddenly equal to that value.

I dont have mirc on this comp, so i dont know the ascii value for '-', so im going to keep it as '-'

why not use

if ($gettok($1-,2,-) == blah) { cmds }

You're using a forced fixed location for the parameters though.. I'm talking about variable(unfixed) locations.

:tongue:

I understand your feature suggestion, and perhaps it'll be a good addition.

Concerning the "fixed location" situation, perhaps your custom operator idea would work here. Creating an isparm that would loop through $mid of the parameters checking each values and returning $true.

if (n isparm) { code }

Although, the OPERATOR idea would require a -l (local) switch itself so it doesn't conflict with others.

I like to use the /server command as an example of what an alias could be expected to deal with..
/server -a irc.irc.irc -p 12345 -g irc -i nick1 nick2 -d irc
1 command line, breaking it up and putting the values into local variables %a, %p, %g and %d (in this example).
This example isn't really directed to you, but more of to try to clarify what I am talking about.

As far as I know /server is the only command that uses that syntax for switches. All other mIRC and IRC commands I can think of revolve around a command -switches switch-parameters command-parameters more-switch-parameters approach. It seems logical that any custom aliases would follow the same syntax if only for uniformity. The syntax you're suggesting is far more complex to use and is typically only used for command-line processing of switches when you run a program, which of course can have literally dozens of switches. For a single command if you've got dozens of complex switches with multiple parameters of variable length it's probably a sign that the command or it's parameters need some rethinking.

I like it, something like a bash (and C, i think) getopts could be useful.

I had suggested an $isflag() or $isswitch() function before, which was shot down on the same grounds of complexity. I personally felt it worked much like the $ini() and $readini() functions, but for enumerating and extracting switches and any corrisponding values.

The greatest difficulty with handling switches is tracking the switch polarity, such as with [color:660000]-oo+oo[/color]. I'm certain that Khaled has already written such a function that breaks down MODE flags and /command switches, internally. All he should really need to do is bind it to an $identifier for us (in theory).

- Raccoon

But switches for a command don't have polarity. If the switch is present then it's on and if it's not it's off, or in the case of options (conflicting switches) then you simply use whichever came first or last depending on your programming style.

Let's say you made a script with 26 different switches...

if (*-a * iswm $1-) { code to find and parse for %a }
if (*-b * iswm $1-) { code to find and parse for %b }
...
if (*-y * iswm $1-) { code to find and parse for %y }
if (*-z * iswm $1-) { code to find and parse for %z }

That seems a bit tedious.

To have /params <option(s)> <$1->
and to have it break it into variable names for you makes it easier.

$regsub is an example of being able to forcefully set a variable to a value
parsing isn't really too terribly difficult, once there is a routine to parse the line from beginning to end. But to put it into a seperate script only cuts down on duplicating the code, you still would have to go through and do constant loops until you got all the values.

Why are you so against it anyway? I mean, it's not like it would make current scripts incompatible, nor would it require 10 lines of code just to use that one function that could greatly improve scripts in the future by making options easier to design.

How is:
if (-* iswm $1) {
if (x isin $1) blah
if (y isin $1) blah
}
any worse than:
param -switches x
param -switches y
if (%x) blah
if (%y) blah
?

I'm not against it as such, I just don't see you're reasoning behind how or why this would be useful.

The use of the -switch value -switch2 value2 doesn't really make sense for IRC or mIRC, it's unnecessarily complex. The syntax only has any advantage over mIRC's traditional switch syntax when you have multiple parameters with variable numbers of parameters - yet still the only way to implement that correctly is with the use of quotes to clearly mark where a switch's parameters begin and end, making the syntax even more awkward. As I said earlier, for something like mIRC commands I think anything requiring that level of complexity of switches is a result of poor command design rather than actual need.

I said ONE call on /param to do the work for you
If you have, as a pure example, 26 possible switches, then which is easier?
(A) /param <opts> <$1->
or
(B) 1 line for each switch (thus, 26 lines)

Now, call me crazy, but I think that 1 call to a function that does all the work for you is a bit easier than writing out 26 lines of code.

Let's take a line like this: $1 = -s server.url.com -n nicknametouse -c #channel -m message to send
/params -at45 $1-
(only ONE call to the entire line)
Now, %s = server.url.com, %n = nicknametouse, %c = #channel, %m = message to send.
And all local variables to the current script.

It seems I misunderstood your meanings for the switches, in that case it's not quite so pointless. Although the variables for the switches still have to be checked at some point so for most cases it wouldn't save any code at all, and I still maintain that this syntax for switches is more complex and 'messy' for mIRC commands and would promote bad command design. That's simply my opinion, we'll just have to agree to disagree.

Yeah, true, have to check the variables.. But you wouldn't have to parse them, which is the point of it anyway. To parse each variable and then perform your functions/commands.
The whole idea is to split the values for you so that you can get right to the point of the script instead of spending a few to several lines parsing the switches first.

And bad command design would be forcing a strict method of using an alias where the switches should be optional or flexible. This would provide that flexibility.