Originally Posted By: XTZGZoReX
Quote:

And, of course, what would there be to tell mIRC what is the alias and what isn't? A script could have both /foo and /foobar as aliases (or separate scripts). It's not like you're making a program that runs on its own and you know exactly which commands (aliases) will be used, so can do something like that.

So what would happen if I made an alias like /timerHello and typed /timerHello 1 1 <stuff here> to call a timer? It's the same thing.


Explain a valid way for those two aliases to function together if other data can be attached to an alias name. You're not doing that and there is no good way to make that work unless you or someone else comes up with some valid method of providing for that situation.

As I stated, in any language that's used to make a standalone program, it's not an issue. You know exactly what is used, so you won't (if you know what you are doing) overlap command names. Therefore, you won't run into problems like with attaching other data to a command.

In mIRC, scripts are not standalone. They require mIRC and many people use scripts from multiple sources. It's quite possible to have one script trying to use /foo and attach data to the end of it and another trying to use /foobar without knowing the first one was attaching data. That's a major conflict situation. Even if you had mIRC only allow data to be attached to the alias if it doesn't make the alias the same as another alias (i.e. it would call the /foobar alias if it saw /foobar, but would call the /foo alias if it was something else, such as /foothat), you'd still have a problem. It would mean that /foo could never have the data "bar" and it couldn't even have "bar*" for data because that would then treat the data as being attached to /foobar instead.

When you start combining scripts, you are going to see more and more conflicts arise. And for what? Just so that you don't have a space? Is that space really so horrible? Do you really think Khaled should waste time making something work for this just so you don't have a space? Do you really think something that can cause conflicts to occur to be allowed just to get rid of a space? Come on, that's rather rediculous.

There is nothing wrong with using:

/foo data

Rather than:

/foodata

It does not in any way improve a script. In fact, in order for mIRC to handle figuring out if it was an alias or an alias with data, and which alias with which data, it would slow things down. And what happens when someone does, for example, a /join alias as /j so it's shorter? That would conflict with all aliases starting with j. Or, for a letter that's used more, what about /s as an alias for /server? That would conflict with all aliases starting with s.

The request is okay for any language doing standalone programs. It is not good for mIRC. And, like I said, that space in there is not going to kill anyone to use it.

Besides, it makes it easier to see what's going on. Let's say I'm going through a script someone wrote to help them out and I see "displaycardsnewclubs". Tell me... what part of that is my alias and what part is my data? And can you easily read it? Wouldn't it be easier to see if it was "displaycards newclubs" ? Or maybe I meant it to be "display cardsnewclubs" or "displaycardsnew clubs"... there isn't any way to know until you search for the alias. In a large script, that is a waste of time. Sure, in this example, you can go by the words and figure that the alias is one of those few possibilities, so you can just try each one. But what about aliases that aren't named using easy to read words? People make aliases that aren't obvious all of the time. Tell me, if you saw "/jump", would you think that's the alias? Probably. But I was using that as alias /j and ump is the data in order to join a player in the position of umpire in a baseball script/game.

I don't know how many examples I have to give to you to show how bad of an idea this is in mIRC scripting, but by now you should really understand that it's not a good thing.


Invision Support
#Invision on irc.irchighway.net