Forums Feature Suggestions Better alias features?

Well, I think the current alias features miss one little feature, to make it work a little like the /timerTimerName command.

For example, say, I'm writing some PHP-like script commands, so I'd like to have the ability to create variables this way:

on *:text:*:*: {
$somevar = sometext
}

However, that is not possible. Sure, I could make the $ alias,

alias $ {
...
}

(Yes, I know it's already reserved for an internal identifier, but that's not the point right now.)

The thing is, I can't, like, return $right() or $left() of the command itself, to set the identifier. At the moment, the only way this whole thing could work, would be with:

on *:text:*:*: {
$ somevar = sometext
}

Which pretty much beats the point of it.

I might be wrong, there might be a way to do it, but I don't know one, that's for sure.

I'd love some opinions on this, and I'm very open to anything.

Thanks!

I don't really understand what you're suggesting. Which bit is like the /timer command? And why would want to use $varname simply because you're writing 'PHP-like commands'?

mIRC already has an existing structure for setting variables, which works just fine.

mIRC is not PHP, it is not TCL, it is mIRC, and thus has a different structure than those other languages. There is no reason to make mIRC act like any other language just so that programmers of those languages can use their brains less when programming in mIRC.

BTW, you can already (almost) do what you are showing in your script.



somevar = hello there

echo -a $somevar
hello there

I don't think that is what you are looking for, but it is the best mIRC can do.

-genius_at_work

That was not exactly what I meant.

Also, I don't intend to use this purely on my PHP-system, but also for many other features that I've (almost) forgotten through time because mIRC doesn't support this whole thing.

Anyone else got opinions?

-- Edit --
Sorry, missed a comment;



As I said, the script I posted above exactly isn't like the /timer command, because you simply can't do that. My suggestions is: Make it possible to use commands such as /commandSomeOptionHere like /timerTimerNameHere.

So you want to be able to use dynamically-stacked commands like /timer can be stacked?

I see no reason to make mIRC act like another language. You have various ways to do similar things in mIRC. Or just use mIRC the way it's meant to be used.

/command someoption
The only difference there is a space. Not exactly a big deal.

/command -switches
This is the same as the first one, but uses switches instead to help make the options visible.

$command(anydata).property
This lets you use $prop to get any option attached to the identifier.


Any of these will do what you want without any more difficulty. Sure, they aren't PHP. mIRC isn't PHP, so what do you expect?

Heh, as I already stated above, I intend to use it on other things than just PHP, I just took my PHP project as an example.


We can already do that, I believe;



... Something like that. Though, using hashtables would probably be better, in this case.

Whether PHP or some other language, the point stands. mIRC is mIRC and not some other language. If Khaled started making mIRC do things found in one language, he'd soon have a lot of people asking for things from many different languages. Where would he draw the line? If he does it for one, why not the others? It may not sound so bad, but consider how sloppy that will make the mIRC scripting language if it starts trying to be a lot of different languages rather than just itself.

In XTZGZoReX's defence, his suggestion isn't actually based on something PHP already does.

What he wants is to be able to create an alias named /foo and be able to call it with /foobar, in much the same way as /timer can be called with /timername.

This idea would likely be quite difficult to implement and slow once implemented. I can't think of any situation where having it would be a significant advantage.

Actually it would be very easy for Khaled to implement the WSH scripting system as it's built into the OS. This gives both JavaScript and VBScript. And would offer a far better alternative to working w/ COM objects then present.

For example,




For example

OK but this has nothing to do with the original feature suggestion, which apparently was to be able to define prefix-based aliases which could have any additional text directly appended to the command name, ie. /aliasnameextratext.

There are ways to do what you want in mIRC script. mIRC is not php. mIRC has its own way of doing things.. instead of changing mIRC to be more like php, change your own habits to be more like mIRC's... you'll find it works just fine

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.

It's not just for PHP - and this particular thing I ask for is not even something PHP does. So, again, this is not something I'm asking for from PHP, I merely used my PHP-to-mIRC project as an example.


Completely 100% correct.


Well, sure, but here you're asking for something that wasn't the point at all; another language. The goal of this suggestion is not to get a second language implemented - thanks for the support though.


Again: This is not a PHP feature - PHP does not even support it. I only used my PHP-to-mIRC as an example.


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.

I think the dynamic alias name feature could be handy. I'd vote for it.

Maybe something like:

alias -w test* echo -a This is $aliasname


/testthis => This is this
/testbanana => This is banana


etc.

On a side note, you shouldn't include unrelated reasoning/requests in your feature suggestions/posts. Clearly, it causes unnecessary arguments that could have made a perfectly valid suggestion be dismissed as useless, etc.

-genius_at_work

but then theres alot of things that become more complex...

what if I have /foo* and /foobar, which would get called when user types /foobar

or perhaps some jerk who visited adds "alias * halt" to my remotes?

and then lets say I have an alias foo* and fooBar is called... how would I find "Bar"?
$1 ? - That would break all existing scripts
or perhaps $extension ? lol

I like the idea TBH, but I dont think it's worth it.
I mean it would break so much and slow down mIRC's input more than allready.

I don't think its a realistic option to implement IMHO.

I think the better solution would be something like:

//fooBar
//foo $+ $replacex(something with spaces here,$chr(32),\_,\,\\)

alias foo {
var %ext $replacex($1,\_,$chr(32),\\,\)
tokenize 32 $2-
echo -at Alias foo was called with extension %ext and contained: $1-
}

I only added the escaping so no one whinges about "what if I have spaces in it?" - even though an alias COULDNT currently support spaces.

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.

Very true, and I have learned from that.

-- @Riamus2 --

I get your point - 100%. There are almost always both pro's and con's in everything.

I do get your point with providing support - You're very correct when you say it would cause confusion.

However, I'm very sure there could be found a workaround for this, instead of just listing all the bad things it could cause. With Khaled and his great knowledge in stuff like this, I do believe it would be possible.

Now, I'm going to jump into something else here, before continueing: Today, I was thinking. Sure, we got the $+ to attach stuff. Say, could a $- not be useful? Think about it. A $- could maybe provide what's needed.

Now, let's get back. Just wanted to write the above, before I forget it again.. Got lots of stuff to think about, recently.

As I said, I do understand you. However, at one point, I might think you're wrong: "In mIRC, scripts are not standalone. They require mIRC and many people use scripts from multiple sources."

Yes, this is understandable. But then again, did you ever notice this in the help file?: "The best script is your own script!"

In the first place, I don't actually think mIRC script was meant to be used as people do it today - develop scripts and distribute them like they were applications.

So, from looking at what Khaled himself has said, you're meant to use your own script - meaning, it's people's own fault if they don't understand the scripts they use (which I'm pretty sure he mentioned something similar to/about in the help file, too).

So at this point, you could say we're equal - It just depends on from what perspective you look at it.

*Pain in hands*

Worth continueing the discussion? If yes, I'm waiting for opinions.

-- Edit --

Oh no, missed you, JD. Sorry.


Of course! If we changed it to $1, we'd doom the mIRC scripting world right away.

I'm thinking about something like, $ext, yes. Then you could probably do, $ext(1) to return first letter, or $ext(3-) to return letters from 3 to last letter, and $ext(-3) to return first 3 letters.. Something in that direction.

Not sure what $- is meant to do in your short comment on it...?

As far as using your own scripts, it's true that your own scripts are often of more use to you than other scripts because it does only what you want/need and nothing else. I have a lot of my own scripts running. That said, most people are not programmers. They don't want to be and/or they don't have the logic (the mathematical definition of logic) skills required to be much good at it. There isn't any reason why we should ignore people who use other people's scripts just so we have certain features that can only help scripters and will hurt non-scripters.

Besides, I think that quote about the best script being your own is really meant as kind of a challenge to people to try and learn. That's just speculation, but it makes sense. It doesn't mean you shouldn't use other people's scripts.

Look at the typical $htmlfree identifier for removing HTML from text. Yes, it's not a large script by any means, but it serves as a good example without trying to think of some specific larger script. If that identifier does what it's supposed to do without problems, why should I choose to make my own instead of use what's already made? There are reasons to use scripts by other people. Or, look at really large (or full) scripts. I could make one, but I don't have the time or patience to do so. If I want to use one, I'd rather pick one that is good and, if needed, adjust it to suit my needs. Again, another reason why using other scripts isn't wrong/bad/etc.

It's good for people to learn to script. Do they have to? No. Should we ignore them just for a benefit to us that hurts them? No. Most people using mIRC don't script, or have very little skill in doing so. You'd hurt far more people than you would help. And I still see no reason why that space is so bad.

I really fail to see how this is useful to anyone.