Forums Feature Suggestions Local aliases

I think this would be nice to allow aliases to be used inside an alias. For example, instead of this:



We could have this:



In that situation, this shorten the code a little bit.. maybe we could say it's useless. But there's a lot of other situations in which that could be faster and could make the code easier to understand.

Yea, pretty useless.

Next we'll want locally-local variables specific to the locally-local alias.

There's really no need to nest something like this. There really isn't.

Well, actually this could be a beggining of objet oriented programming, it would be pretty usefull

Yeah, great idea

I like the idea. I think it could be very useful.

Now what about the evaluation of parameters? Assuming 'alias' will be treated as a command here, should it evaluate the parameters being passed to it or just leave them 'as is', except maybe the pipe separator?

If the developer chooses the first option, it will be such a pain to write those aliases, endlessly calculating how would they look after getting "compiled".

And if he chooses the other way, how would we build a static alias out of dynamically stored commands?

Umm... what in the hell are you talking about? It would work just like any other alias, except local to a function.

Right, but here alias will be a command name and not a remote prefix, that's why it's important not to evaluate the parameters following it.

Not all commands are evaluated immediately. Otherwise, /set would never be able to get the variable name.

I've yet to hear a good reason why this would be very useful ("very" as in "useful enough to consume a part of Khaled's precious time in developing mirc"). The only use I can see is having shorter names for aliases. Meaning that this feature would allow single letter aliases of the same name, like this:as opposed to the current way:
I don't even consider saving letters necessarily good because it could lead to less descriptive alias names (if the aliases foo and bar were huge and each of them used a bunch of $i()'s, don't you think that this could cause some confusion as to what $i() does?)

Do you think saving a few letters from alias names is "very" useful or do you have a better use in mind? Oh and before you mention something like "other languages support that", I don't find this argument strong enough. We're talking about mirc, which means we should take into consideration the nature of the mirc scripting language, the development status (one-man project) as well as the scripters base.

That is a great idea

qwerty:
Well, your example is an use of the suggested feature, but I could simply want it to organize many parts of my code.

General reply:
Is this really worth it? I mean, I think it's a good idea and would use it a lot, but do we need it? We don't. Maybe many wouldn't get even close to "need" it.
But I believe that anyone who answered this question would also point a lot of features that aren't really needed, but improve a job, and I think the same point could be applied here.

For example, /var sets local variables, but we could use the undocumented /set -l or the documented /set -u. Granted, /var accepts a list of local variables, but since it isn't capable of setting a list of global variables as well, I assume it's prior feature is setting local variables. So it's an improvement, but not really needed.

I know this suggestion is much less needed when comparing to /var's improvement, but it still improves something, even if a little. And maybe it could bring room to more improvement in the future.

So, IMO, its value/worth only depends on its difficulty to be developed by Khaled.

Online:
It wouldn't necessarily need to be declared with "alias". It could be "lalias", "local", "whatever", then from that point the given name would prior the feature. Meaning you couldn't have an alias called "local" or "whatever" (that could still break some scripts, but ctrl+f+replace would be the finest solution) and also that the parser would treat it differently. I don't know the consequences of this, if it'd slow down parsing etc. but then again only Khaled could know and decide if it's worth it.

Ok, I started out writing a post giving a small case study of different implementations of this. Half way through, I realized how stupid it was.

My conclusion: aliases within aliases is useless, and would only serve to complicate the language without giving any improvement. This is based on both the "aliases within aliases as a quasi class-and-method implementation" and the "aliases within aliases as just that" implementation.

It's just useless. Sorry.

And your arguments are...? Sorry, I'd like to know.

My arguments for not introducing such a feature in mIRC is that 1) it's useless (as stated in my previous post) and 2) it will complicate the code unecessarely (also mentioned in my previous post), not to mention the parser speed setbacks.

I was asking about being useless and complicating. Many features could be considered "useless" by one and they're still added. I don't get why should it be different now. I also don't get how could it complicate the code. I get, though, the parser issue, but again I think this is up to Khaled.

Useless? Well then let me ask, why is your suggestion of constants so much more "useful"? alias -l someconst { return somevalue } would emulate a constant rather nicely. So why is your suggestion so much better?

How will it complicate code? I see it simplifying code. Instead of having, for example:

alias output_notice { echo -t @notices $1- }
alias output_msg { echo -t @msgs $1- }

alias my_notice {
.output_notice $1-
}

alias my_msg {
.output_msg $1-
}

where as with local aliases:
alias my_notice {
alias -l output { .echo -t @notices $1- }
.output $1-
}

alias my_msg {
alias -l output { .echo -t @msgs $1- }
.putput $1-
}

Now thats not the greatest example, but it shows the point. You no longer have to have super descriptive alias names or things like dosomething1 and dosomething2 to avoid naming conflicts. If the alias is only needed within a single alias, why not make it local?

And parser speed setbacks? Are you using a 286? I'm not, I'm using a relatively slow PC, and thats a 1.4Ghz. They already have processors more than double mine. The "speed setbacks" you are talking about are 10nanoseconds. Yeah, 10 billionths of a second. Are you honestly going to tell me that 10ns is so important to you that people should be
deprived of this feature so your script runs in 10 seconds rather than 10.000000001 seconds?

Oh and again I ask, why exactly does local aliases create such complexity and speed issues yet your constants suggestion doesn't?

You are obviously not familiar with common programming philosophy and/or structure. I will not continue any discussion related to my suggestion of adding constants with you since it's obvious that you are quite uneducated on this matter. However, please stop bringing up out-of-context posts. Use the appropriate thread for it if you want to comment on it.



I will not argue with you about your personal taste for coding (which however I find to be quite perverted by looking at your examples), I can only appeal to common sense on this point.



Many small nanoseconds can make up quite a few seconds in the long run. mIRC's script parser is already slow as hell, adding severe structure altering crap such as aliases within aliases would ONLY serve to make the parser even slower.

I mean COME ON!! When did you EVER see a interpreted language with functions inside functions? Or a compiled language for that sake? There's a REASON you know!

!"#¤



By now this should be obvious. If you need to learn more about programming, I advice you to use www.google.com.

I've been programming for about 10 years now, I do NOT need you to come and tell me I don't know what I'm talking about. All your reply said is "I'm not answering that" or "That's a matter of opinion" give me a break! So because your opinion is it is complex and useless it shouldn't be added? Isn't that a matter of opinion? If you are dismissing my opinion that it is NOT complex and it is NOT useless I can just as easily dismiss yours.


Python supports local function definitions. Pascal/Object Pascal/Delphi supports nested functions (as does Innerfuse Pascal scripting, an interpreted language). Algol supports nested functions. The C++ library Boost supports local functions in the form of Lambda functions. The gcc compiler will let you use a local function in C. Fortran 90 includes "contained functions" which are essentially local functions. As of Perl 5, perl supports nested functions (perl is also an interpreted language). PHP supports nested functions (PHP is also an interpreted language). (Edit) I forgot, Ruby also supports nested functions (Ruby is also an interpreted language). Also in C++, you can declare a local class which in turn can have member functions which then act as local functions. Java also supports function local classes. Javascript also supports local functions (Javascript is also an interpreted language).

But you're right, I'M the one who needs to learn more about programming because I don't know what I'm talking about. So I guess you must be right, no languages support nested functions... except the dozen languages I just mentioned there. I'm sure there are many more languages that support nested functions, however I think I've proved my point.

I stand corrected, nested functions are existent within several languages, both compiled and interpreted ones (I would however like to point out that classes is a whole other story).

Still, the fact remains that adding such structural changes to the mIRC scripting language is very likely to decrease performance severely. However, if you really think that the parsing engine in mIRC is built in such a way that this would not make any notable* difference in execution speed, you are naive. And I might as well be paranoid. Let the benchmarks decide

The reason I'm so engaged in this issue is that I am currently working on a very large and cpu-demanding script that has caused me alot of headaches performance-wise. I would hate to see mIRC become even slower.

* By notable I mean seeing a distinct difference in performance when benchmarked