Global identifiers within event processes - 22/02/05 03:30 AM
Here's the deal. Code could be much more intuitive if event triggered script processes made its identifiers global within the process of the script
Example:
Currently, mIRC will not be able to parse the $nick in somealias and will return null. But it would be nice if all identifiers generated by an event process were set and maintained globally through the entire script process, so that any concurrent function calls would be able to use the identifiers without having to pass them as parameters (which can be ugly and become confusing)
One extremely useful application for this is the recently introduced SIGNAL, which doesn't really get much attention from scripters- and I think one of the main reasons is that it's so confusing to use, since everything you need has to be passed to the signal before you can use it.
Consider the following, first as it currently is, and next with global $identifiers in a script process
The first one is clearly much harder to debug, as well as maintain: if you wanted to add another $identifier, say... $wildsite, to the signal, you'd have to not only add it to the signal event, but pass it to the signal as well, and change all the parameters in the signal, because everything will be pushed up by 1 (its now $5- for text)
The second one on the other hand is clear and concise. Though i did bring up one issue in the example itself, which is the handling of $1-. MY answer to that would be, $1- (and $1 and $2, $1-2, etc respectively) would be a special case that mIRC would _not_ make global, and would have to be passed to the signal.
There are many other practical uses to this, don't think it would be _too_ hard to implement either. It would sure make me love signals a whole lot more.
Example:
Code:
alias somealias { echo -a $nick } on *:TEXT:*:# { somealias }
Currently, mIRC will not be able to parse the $nick in somealias and will return null. But it would be nice if all identifiers generated by an event process were set and maintained globally through the entire script process, so that any concurrent function calls would be able to use the identifiers without having to pass them as parameters (which can be ugly and become confusing)
One extremely useful application for this is the recently introduced SIGNAL, which doesn't really get much attention from scripters- and I think one of the main reasons is that it's so confusing to use, since everything you need has to be passed to the signal before you can use it.
Consider the following, first as it currently is, and next with global $identifiers in a script process
Code:
on *:TEXT:*:#:/signal TEST $nick $fulladdress # $1- on *:SIGNAL:TEST: { echo -a $1 / $2 said $4- on $3 } - or - on *:TEXT:*:#:/signal TEST $1- on *:SIGNAL:TEST: { echo -a $nick / $fulladdress said $1- on # }
The first one is clearly much harder to debug, as well as maintain: if you wanted to add another $identifier, say... $wildsite, to the signal, you'd have to not only add it to the signal event, but pass it to the signal as well, and change all the parameters in the signal, because everything will be pushed up by 1 (its now $5- for text)
The second one on the other hand is clear and concise. Though i did bring up one issue in the example itself, which is the handling of $1-. MY answer to that would be, $1- (and $1 and $2, $1-2, etc respectively) would be a special case that mIRC would _not_ make global, and would have to be passed to the signal.
There are many other practical uses to this, don't think it would be _too_ hard to implement either. It would sure make me love signals a whole lot more.