Forums Feature Suggestions Suggestions regarding /noop

For consistency's sake, I think it would be nice to officially have the identifier equivalent of /noop, being $noop()

I would like for both /noop and a hypothetical $noop() to be unoverridable by scripted versions. Currently, coders are basically forced to use !noop to ensure that the correct noop alias is called. It would be nice to be able to know it can't be overriden, so we don't need to include that exclamation mark all the time. (It is common to use !.echo -q, which is basically the same as the new /noop)

The same would have to apply to $noop() make it unoverridable, as here the case is worse, you can't really use it because you can't use ! to make mIRC call the built-in version like you can with a command. (technically there is a way, but it doesn't help for our case)

Currently $null() also suffers from this, the fact that a user may have a null alias installed, means you cannot use $null() in your scripts.

I like the identifier thing.

But what makes the /noop command so special that you need special behaviour (making it not overridable)? Any script or alias file could override pretty much any other mIRC command, including /set, yet you can trust all of these to work properly because a sane user wouldn't use aliases that will break scripts they use by overriding built in commands.

And it's not worth it going to this much trouble, and sacrificing flexibility and readability, just to make sure it'll work for those users who are not sane. That is a lost cause.

What does it do anyway?

There are scripts out there that have a /noop alias already, not because the scripters weren't sane but because a built-in command didn't exist (and they probably didn't know/like !.echo -q). A /noop that can't be overriden would be convenient until the /noop aliases begin to fade out (which I suspect it'll take quite a few versions of mirc). Does this warrant the exception? I don't know, but I know for sure that I'll be using !noop in any public snippets for quite some time.

I actually had a scripted noop alias on 6.16, it's not so unlikely at all as you may think to have one.

Since you think no sane user is going to override /noop, then surely you won't mind losing this little bit of flexibility of being unable to override this one specific command, right? I mean it is clear you won't be overriding it, so why would it matter to you anyway?

Those who do use it extensively in public code will benefit from it, which is after all the reason for my post.

noop stands for "no operation". It means you are passing some parameters to the noop command, where the parameters on their own aren't very important, rather the consequences of evaluating these parameters. So basically you are telling mirc: I want these parameters to evaluate, but I don't want to do anything with the results of the identifiers (don't do an operation with the results)

Examples:

noop $regex(moo,(.))
echo -a $regml(1)

noop $findfile($mircdir,*,0,echo -a $1-)

noop $com(object,property,2)
echo -a $com(object).result

In all cases we are not very interested in the results of the identifiers, but we are interested in the consequences of letting them evaluate. For the regex, we needed to issue it in order to fill $regml, for the $findfile we wanted to let that echo execute on each file without doing anything with the total number of files (which is what $findfile returns in that example). The example with $com will retrieve a property from a certain object, which is stored in $com(<obj>).result, but in order to get this result we first gotta make that call to $com evaluate.

Good explanation, I had just read the whats new, and was trying to think of what a /NOOP command could have been for.

AS for not beinga able to over ride it, I dont like that idea, in the future Im sure someone well want to override it for some odd reason.

My personal thought is all $identifiers should be overrideable also maybe with a extra switch, like alias -l for local alias, but -i for identifier (only?) alias.

MY other REAL gripe is how aliases in the ALIAS section take pressidence over the remotes section, I beleive it should be the other way around, reasoning is that by carefull manipulation of groups, you can replace a default command such as /echo, and then have your alias call echo again allowing anyone elses custom alias of /echo to function as well with your manipulated data, however if there is an /echo alais under alieses, your out of luck.

(sorry for off topic)

I didn't say a sane user wouldn't override it. Backward compatibility is probably a very good reason to do so, and I wasn't aware that people were using it before. What I don't think a sane user would do is override it so that it breaks scripts.

Do the current popular noop aliases do nothing, and if so, what's the problem?

If some of them do have an effect, then scripts with that alias will be broken in some way no matter what you do. Making /noop not overrideable would cause the other script to break instead of yours.

There are two ways to cope with that situation (where there are common broken /noop implementations, which may or may not actually be the case). One is to make your own noop alias, which always does nothing (alias noop return); this would probably make things slower, but it has the advantage of backward compatibility. The other is to use !noop all the time and require mIRC 6.17.

So if a lot of people do currently have a /noop alias that does something, then I would say, yes, it should be made unoverrideable. Maybe some breakage could be avoided by making the aliases work if called from the same file.

And no, I wouldn't mind the loss of flexibility. There probably are no practical uses of overriding /noop with an alias that does something. But however small, it is a loss, and it should only be considered if there are real advantages, not just theoretical problems it would solve that no one really ever has or probably ever will.

idents cant be overriden.
from the help doc:

Note: Built-in identifiers of the same name have priority.

if im not wrong, that means that $null or $noop cant be overriden

They can.

First try:

//echo -a $null($regex(a,(.))) $regml(1)

--> a

Then put in your remotes:

alias null return You're wrong.

Then try:

//echo -a $null($regex(a,(.))) $regml(1)

--> You're wrong. a

Thanks for playing.

It is worth noting that mIRC differentiates between identifiers that take parameters and those that don't when choosing between built-in identifiers and custom aliases.

If the built-in identifier takes parameters it will always be used when that identifier's name is used with following parentheses. However, if that same identifier's name is used without parentheses mIRC will use the custom alias instead.

alias rgb return Moo
//echo -a $rgb
--> Moo
//echo -a $rgb(255,255,255)
--> 16777215

If the built-in identifier takes no parameters then it will always be used when that identifier's name is used without following parentheses. However, if that same identifier's name is used with parentheses then mIRC will use the custom alias instead.

alias me return Moo
//echo -a $me
--> Collective
//echo -a $me()
--> Moo

Some identifiers (such as $nick) are not overridable at all as they exist in both $nick and $nick() forms.

alias nick return Moo
//echo -a $nick
--> * /echo: insufficient parameters
//echo -a $nick()
--> * Invalid parameters: $nick

Unless I have missed something in my skimming of this thread, this would mean that $noop() does not need special treatment.

-insert vaguely amusing put-down here-

As for the actual suggestion:
$noop() would be a nice addition

Given the fact that mIRC is often modified with backwards-compatability for scripts in mind, it would seem to be a break with tradition to treat /noop specially. Due to that, and the points made by previous posters, I would prefer that this was left alone.

I know that. I bet you assume I didn't know that because I requested for $noop() to be unoverridable. I request that because I am keeping in mind the way $null() currently acts with its overridable behaviour! I'm sure you will argue that it's because there is also a $null (without parameters) and there wouldn't be a $noop without parameters, but unless it's implemented we won't know how it will be. What I'm saying is that if it gets implemented, I don't want it to be overridable. If it turns out that this wouldn't ever be an issue anyway, well great, even better.



Why is backwards compatibility a factor here? /noop has only been introduced with the last version. In fact many people are still clinging on to .16 waiting for a bugfix release. Besides, it's not like mIRC hasn't ever broken scripts due to changes, remember $null's behaviour changing in an older version, which broke a lot of scripts. I'm not saying my argument is better than yours, rather that both our arguments aren't really an argument, as examples of both cases exist.

There is no $null() identifier. Turn on Identifier Warning and you'll see.

It's a word that starts with a $ and is interpreted in mIRC. Sounds like an identifier to me. Yes $null()'s usage isn't explained in the help file, though is it relevant? There are numerous things unmentioned in the help file that do exist in the scripting language. Seeing as how $null() acts the way you would expect it to do, and it does so consistently, it is fair to assume it was created with the intention to also work as a $noop() although of course only Khaled can clarify this.

No. As far as mIRC is concerned, $null() doesn't exist. It is not a built-in identifier, and therefore what you said to FaiNT is completely besides the point. The fact that it does what you expect, is only a side effect of the fact that an identifier that doesn't exist, returns nothing - again, if you turn on Identifier Warning in remote, then you will see that its use generates a warning.

It indeed returns an error message, denoting it wasn't intended behaviour on Khaled's part after all. Oh well. Then I can drop the unoverridability part of the request regarding $noop (I'd still like this for /noop) and change the request to just be to officially add $noop() so that a scripted equivalent cannot interfere anymore.

I know you already know this, this is a general reply for anyone interested in this feature.

You can use direct recursion to mimic an unoverridable $noop(): alias x return $x($regex(abc,/a(.)c/)) $regml(1)

Indeed, zzattack was the first one I saw doing this. It's good to mention it. There are two important things to note:

1) It only works in the case of an alias, not usable in an event or from the command line.
2) For someone reading code, it is a lot more straightforward to have a uniform identifier such as $null() or $noop().

Other than that I agree, it's quite handy, although maybe this is just us again relying on a quirk such as the $(,,<input>) thing that we unfortunately can no longer use since version 6.17.

Oops I was going to type out a disclaimer about that but must've forgot, heh. Here it is:

The trick above is undocumented and subject to change at any time, don't use it if you don't feel like rewriting a whole lot of code should this happen, yadda yadda.....

Actually I was assuming you were capable of taking a hint. The hint being that $null() doesn't exist, but $noop() would and hence wouldn't be overridable.

Turns out I was wrong, since you needed the two replies from Sat that spelt it out before you caught on.

I was replying to your arrogant and inaccurate response to the polite and correct point made by FaiNT (who you'll note said $null not $null()).


The only reason you think /noop should be non-overridable is because some scripts come with a /noop alias. If mIRC made /noop non-overridable then those scripts would cease to work (assuming that their /noop alias did something). If the script's /noop alias did nothing then there is no problem in the first place.

Of course, madewokherd already said exactly the same thing.


It has done it before, but you don't need to look far in versions.txt to find a number of places where depreciated features have been left in for the sake of compatability.