I'd like to see a switch for /bvar commands that would allow the set binvar be persistent until a script/user unsets it or mIRC is closed(obviously) instead of having to store them in a hashtable.

/bset -p
/bcopy -p
/bread -p

The reason I ask is because I like to write stand alone script files(One script does not depend on anything from another) and currently, with this format I have a different hashtable with a single item in it for each &bvar I want to recall later on. It's either that or save the &bvar to my harddrive.

/bset should work just like set.

/bset &bvar [data] ;-- global persistent bvar
/bset -u &bvar [data] ;-- global persistent bvar auto unsets at end of execution.
/bset -l &bvar [data] ;-- local bvar

[data] is optinal. /bset would always declare the type of bvar (global/local) to be used.

Mysterious double post... weird...

EDIT: AUGH WHAT IS GOING ON?!? I edit it creates a new post? This is the last attempt at a post since I don't know what will happen when i click submit.

Not sure where you're getting your syntax from, but -l and -u aren't listed as switches for /bset. Also, binary variables are not persistent. It will unset automatically after the script is done with it. For example, you can't /bset from the edit box and hit enter and then /echo the binary variable. That's why the OP wants a switch to make it persistent.

He said where he was getting his syntax from, and already knows that binary variables are not currently persistent. He's suggesting /bset be changed behave to in the same way as /set (persistent by default with switches for local variables/timed unsetting).

Edit: Fixed quote.

Ok. I see that now. I had to re-read that. I thought he said it was the same as /set, not that it should be the same as /set. Ignore my post.

Btw, the duplication seems to have happened when you quoted me as well... you have a duplicate sentence in the quote that isn't duplicate in my post. I think the forum needs to be looked at soon. We don't want to start losing posts. Duplicates are bad enough.

If any, it should rather follow /var syntax (local unless the -g switch is used). Else you'd break lots of scripts - the scripters assumed their binvars to unset self-acting.

/var executes /set -l not /set -u0 (which is what it executes now). Anyone who currently calls /bset is overwriting the value. Honestly it doesn't matter. Whichever. There's always the possibility that a change will break scripts. This is unavoidable.

yup. You missed the whole point of my request(Which you seem to do alot). Why have bvars function the way was /set|/var does? If you changed the format of them, it would mess up backwards compatiblity, breaking a lot of scripts.

The -u switch is a good idea, if it was to be used with the suggested -p switch. The -l switch is unless, if what I suggested is implemented.

1) You can persist binvar data in a hash table, so all we're talking about is a convenience switch here.
2) You don't need to use a separate hash table, you can put them all into "some_unique_htable_name" using different key names.

Implementation-wise, I imagine having Khaled redesign bvars to flag global ones and keep them live after a script ends would be fairly complex and not very attractive to implement, given that it doesn't even lead to functionality you don't already have.

Even though it is possible using hash tables and other means, I do think adding the ability to make binary variables persistent is a good thing.

You listed 3 commands... what about the other 20 or so commands/identifiers that use binvars? They all going to need a -p switch too?

the switch would only be suitable for functions that create bvars, of which there are a limited number (in addition to what he mentioned i can only recall /sockread off the top of my head, and of course $hget()/$fread() which aren't commands though switches could still be implemented).

i'm afraid i can't rally behind this suggestion since, as argv mentioned, persistent bvars can already quite comfortably be coded with the use of a hash table. and if it were to be considered, we would also have to add a $var() counterpart for bvars to keep track of those that have been set as persistent, otherwise it's very possible to lose track of them all, some of which could be hogging large amounts of memory. should we choose to use a hash table to house our persistent bvars, this method of keeping track is already offered with $hget().

The reason I ONLY listed those three commands is b/c that's the only 3 you would need to mkae binvars presistant


simple as that. Why have khaled go though and fix sockread/fread/etc, when the implomention of just those 3 would cover all you need.

Also, Jaytea, I see what you mean by the need for something to such as $var() for the binvars to see what is presistant and what not. I guess I didn't really think it through as well as I thought. Though it would be a nice idea, for Khaled to do it, and keep backwards compatiblity would be quite hard

And with that, This thread can be deleted.