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
It likely will have some impact, but the way I envision it, and of course I've never actually seen the mIRC code so I could be completely wrong, it should only have an impact if you actually make use of it. Meaning I see it as something like this:
if (has_local_aliases) {
all the stuff to handle it
}
meaning if you're not using it, there really should only be 1 if check, and that if check would be to determine if there are local aliases defined. The way I see it, it would just sorta have the be an extension of the alias -l. Meaning what I assume alias -l does is (internally) translates say alias -l blah into something like script1.mrc.blah meaning it keeps track of which ones are in which file. So for nested aliases it would just do something like script1.mrc.theparent.thenestedalias or something along those lines.
Oh and furthermore about your very CPU intensive script. I'm personally someone who believes such things are not what mIRC scripting is designed for. The way I see it, mIRC scripting was designed more for stuff like flood protection and auto identifiers, and things of that nature. Not, picwin GUI, 3d libraries, games, etc. While it can do those things, I personally feel that those things should not take precedence over the more common scripts simply because to a huge script 1ns might make a signifigant difference.
Of course the issue of what kind of impact it would have could easily be rectified if Khaled would comment on this. However, since he's never really made any comments on language extensions before, I doubt that will happen.
