mIRC Home    About    Download    Register    News    Help

Print Thread
#22546 05/05/03 04:54 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
One of the biggest problems (imho) in mIRC scripting are variable conflicts (ie, mp3 player has %sayinchan and away script has %sayinchan). Below are two possible solutions to this problem, the first is probably easier, but the second is more comprehensive.

1.) Script level variables
/svar %sayinchan = 1
An svar works sorta in the middle of a local var and a global var. What I mean by this is, it is accessible by ALL events/aliases/etc that are in the same file that originally created the variable with /svar. This means for example, I can have all my configuration variables and never have to worry about variable name conflicts, because /svar guarantees that if I have %sayinchan in mp3.mrc and in away.mrc, if they are created with /svar, then they are different variables. Additionally, for scripts that span multiple files, there could be an identifier, $svar(filename,varname) that allows you to retreive the /svar's of another file.

2.) Namespaces
namespace mp3 {
....
}

This is something that is available in other languages. The purpose of it is to resolve ALL name conflicts, not just variables. For example, I have inside namespace mp3 an identifier called isplaying, to access this I could (from inside namespace mp3) do $isplaying, but from outside namespace mp3 I'd do $namespace(mp3).isplaying (similar to using $scon stuff). A similar thing could be implemented for variables so that you know you are getting the correct variable. This would also resolve the "I want multiple ON TEXT in the same file":

namespace text1 {
ON *:TEXT:blah:*:{
.....
}
}

namespace text2 {
ON *:TEXT:blah2:*:{
.....
}
}

Then, even though they are in the same file, mIRC would be able to recognize them as seperate scripts because of the different namespaces.

Crazy? Of course! But still a nice idea imho.

#22547 05/05/03 05:07 PM
Joined: Jan 2003
Posts: 3,012
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
Not to go against you, and make your well-done essay seem useless, but what is wrong with typing %mp3.sayinchan or %away.sayinchan and almost make a public class variable out of it?


-KingTomato
#22548 05/05/03 06:18 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
codemastr raises a valid point though I agree too with what you said. It is the correct protocol when scripting, especially when you do it for other people to place two expressions in the variable name with a fullstop between them.

EG: %this.that

As a rule of thumb I prefix all locals and globals with two initials relating to the name of the script or addon I am making.

EG: Watchdog Script would have %ws.blah

#22549 06/05/03 02:22 AM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
I agree, but say I want to load two different mp3 players. And say both of them use %mp3.sayinchan, the same problem arises.

#22550 06/05/03 02:30 AM
Joined: Jan 2003
Posts: 3,012
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
And again, why would load two scripts? Not only that, what are the chances that they use the exact same file names. If they do use the same names, such as %mp3.dir, how would it matter if your directory was the same for either script. In addition to that, say you do have 2 mp2 scripts, would you use them at the same exact time? All i need to say is get used to using prefix.var


-KingTomato
#22551 06/05/03 03:13 AM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
You made no sense there at all. What does a filename and directory have to do with anything? Nothing at all. I would comment on the rest of your reply, but frankly, I don't understand a word of it.

#22552 06/05/03 12:29 PM
Joined: Feb 2003
Posts: 32
S
Ameglian cow
Offline
Ameglian cow
S
Joined: Feb 2003
Posts: 32
If SVAR exisited I would probably use it all the time instead of regular globals. It would allow me to have simple names for my 'global' variables, without having to tack on silly prefixes.

On the topic of conflicts... By far the most annoying conflict for me personally, is the possible conflict between @window names. IMO a @window name should just be a caption, and we should be able to address the window through it's HWND, or somether unique ID. (An extra switch in the /*line commands and the /draw* commands to indicate a HWND was specicifed instead of a @window).

#22553 06/05/03 03:58 PM
Joined: Jan 2003
Posts: 3,012
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
Let me put this in simpler terms for the layman.

You had mentioned loading two scripts. Now you also had said what if the scripts use the same variable and prefix (e.g. %mp3.sayinchan was ur example) Now, what is the harm in having the preferences carry over for both scripts. If you don't want an mp3 advertisement in one, why would you want it in the other. In fact, that more a benefit than a discouragement.

I also explained why would you have two scripts loaded with the same purpose. Say you did have two loaded, would you have both in operation at the same time?

My point is, if you don't want the problem to occur, make the identifiers as unique as possible. My mp3 player uses an Ini so such things don't happen, but I could just as well used ktmp3 for KingTomato mp3, and avoided the problem right from the start.

My example was something like %mp3.dir (the assumed directory your music is located) Why would you want to have a different value for both players? Same with most other variables. If they have the same name, chances are they have the same purpose.


-KingTomato
#22554 06/05/03 07:03 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Just because the variables had the same name doesn't mean they store the exact same info.

People could have two scripts of the same type loaded for a dozen reasons, eg. someone uses a full script containing a basic mp3 player and also wants to use an mp3 addon which is much more advanced. Or if you named your variables as Watchdog suggested then the scripts might be totally different but have the same initials.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
#22555 06/05/03 09:14 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
perhaps mp3playerA uses %mp3.sayinchan to say "I'm playing songname.mp3" where as mp3playerB uses %mp3.sayinchan for "I'm using mp3playerB get it at http://..."

Quote:

My point is, if you don't want the problem to occur, make the identifiers as unique as possible. My mp3 player uses an Ini so such things don't happen, but I could just as well used ktmp3 for KingTomato mp3, and avoided the problem right from the start.


Well in your scripts you are free to use %myscript.mymp3player.settings.the_option, me, I want to be able to just call it the_option. If you want to make more work for yourself, even if svars were implemented, nothing would stop you from using the current system. The idea that "there is already a way to do this" is great if I said "can this be done", but thats not what I said, I said "there should be a better way to do it." If "there is already a way to do this" was a valid reason for not adding things, then please explain why while() loops were added? goto loops worked just fine for everyone before while loops came around. Why was /tokenize added? You could get the same effect using $gettok. The reason why these and other things were added is just because something can be done does not automatically mean there isn't a better way to do it. I'm just glad most computer programmers don't take the stance that "there is already a way to do it" or else computers would be incredibly slow. Why? Over the last 20+ years programmers have said "yea this works, but I can find a better way, one that is faster and more efficient" this has lead to many great advancments.

#22556 07/05/03 12:45 PM
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031
Well said.

#22557 08/05/03 04:40 AM
Joined: Feb 2003
Posts: 309
C
Fjord artisan
Offline
Fjord artisan
C
Joined: Feb 2003
Posts: 309
possible (messy) fix:
pretend the script is a COM object and use getters and setters
For example: a getter.

alias -l get {
return $eval($+(%,obscure_long_name_thats_not_meant_to_be_seen_by_user.possibly_md5_hash.,$1))
}
would work better inside of a scripting framework, but gone is the need to worry about some 13 yold using your var name.

OR
create 'namespaces' by simply making external vars files (hash tables even) for each script and processing them with the script... you'd also be able to restrict access a little by encrypting the lot (MUAHAH PRIVATE VARS!), whihc is pretty much what you have done

I might nab the idea for my MEAR framework

#22558 08/05/03 05:45 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
Well since you compared it to COM, that sorta implies object oriented-ness. mIRC doesn't support objects. therefore even $get/$set would get messy, simply because they are not tied to any one object, although local, they are still global within the file. But, I wouldn't mind seeing mIRC support OOP wink


Link Copied to Clipboard