mIRC Homepage

Suggestions regarding /noop

Posted By: FiberOPtics

Suggestions regarding /noop - 17/02/06 10:31 PM

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.
Posted By: madewokherd

Re: Suggestions regarding /noop - 18/02/06 01:00 AM

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.
Posted By: Jigsy

Re: Suggestions regarding /noop - 18/02/06 01:05 AM

What does it do anyway?
Posted By: qwerty

Re: Suggestions regarding /noop - 18/02/06 01:34 AM

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.
Posted By: FiberOPtics

Re: Suggestions regarding /noop - 18/02/06 01:52 AM

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? smile

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

Re: Suggestions regarding /noop - 18/02/06 03:02 AM

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.
Posted By: DaveC

Re: Suggestions regarding /noop - 18/02/06 06:35 AM

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)
Posted By: madewokherd

Re: Suggestions regarding /noop - 18/02/06 10:00 PM

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.
Posted By: FaiNT

Re: Suggestions regarding /noop - 23/02/06 08:29 AM

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
Posted By: FiberOPtics

Re: Suggestions regarding /noop - 22/03/06 02:12 PM

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.
Posted By: Collective

Re: Suggestions regarding /noop - 22/03/06 03:49 PM

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.
Posted By: FiberOPtics

Re: Suggestions regarding /noop - 22/03/06 07:03 PM

Quote:

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.

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.

Quote:

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.


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.
Posted By: Sat

Re: Suggestions regarding /noop - 22/03/06 07:16 PM

Quote:
I request that because I am keeping in mind the way $null() currently acts with its overridable behaviour!

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

Re: Suggestions regarding /noop - 22/03/06 07:23 PM

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.
Posted By: Sat

Re: Suggestions regarding /noop - 22/03/06 07:27 PM

Quote:
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.
Posted By: FiberOPtics

Re: Suggestions regarding /noop - 22/03/06 07:48 PM

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.
Posted By: hixxy

Re: Suggestions regarding /noop - 22/03/06 08:05 PM

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)
Posted By: FiberOPtics

Re: Suggestions regarding /noop - 22/03/06 08:08 PM

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.
Posted By: hixxy

Re: Suggestions regarding /noop - 22/03/06 08:16 PM

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.....
Posted By: Collective

Re: Suggestions regarding /noop - 23/03/06 05:00 AM

Quote:
I know that. I bet you assume I didn't know that because I requested for $noop() to be unoverridable.

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()).

Quote:
Why is backwards compatibility a factor here? /noop has only been introduced with the last version.

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.

Quote:
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.

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.
Posted By: FiberOPtics

Re: Suggestions regarding /noop - 23/03/06 10:08 AM

Oh don't worry, I know I am arrogant at times, it's only natural that something like that sometimes fires back at me. I'm not going to change because of it, it's a risk I'm aware of and accept, sorry you had to take out your markers grin But realize that you really aren't much better with your last post, it has arrogance written all over it, not to mention personal attacks far from relevant from the feature suggestion.

This is the feature suggestions forum, if you have a problem with my attitude, feel free to pm me though.
Posted By: Foster

Re: Suggestions regarding /noop - 31/03/06 04:03 PM

From a software developer's standpoint, it's important to have consistency in behaviour. It would be bad programming practice to make some commands overridable and some commands not.

That being said, a convention has already been put in place to allow a scripter to account for the fact that some other script may have overridden a command - that is, prefixing the command with the ! operator.

Asking for the noop command to be non-overridable simply because you don't want to put a ! in front of it demonstrates lazy and poor coding.

However, it would also be poor coding if a command was overridden in such a way that its functionality was radically changed (ie, making /msg be a /quit). Commands should be overridden if you intend to add additional functionality to them (although it may be excusable if you intend to make the command do nothing, such as to prevent the user from using the join command, although something like that really belongs in an on INPUT script).

That being said, I think that the current functionality of noop should be preserved.
© 2019 mIRC Discussion Forums