That's not really a valid counterpoint. Hash table names are also public. Using /hfree, /hdel, or /hadd would corrupt the script in the same way.

If you have a variable that you don't want overwritten, simply namespace it appropriately (%scriptprefix.some.name) and it should not get modified unless the user really wanted to change it. In the latter case, the user could do the same with your hash table. Incidentally, /hrename makes it even easier for an outside user to do this, so this feature suggestion actually creates the same problem you're trying to avoid with variables.

The reality is that everything in mIRC is open for modification, including the very logic of your script. Even if mIRC had a "private" modifier on variables, it would be trivial to modify a script and change that if a user really wanted access. The issue I think you are raising is accidental modification, but as mentioned, with proper scoping, you can easily avoid this.

As a sidenote, if you're worried about the variables section being completely wiped (something you may want to account for), you can do something like:

Code:
; ensure %myscript.tablename is always set
alias -l find.table {
  if (%myscript.tablename) return
  var %i = $hget(0)
  while (%i > 0) {
    if (myscript.tableprefix.* iswm $hget(%i)) {
      set %myscript.tablename $hget(%i)
      return
    }
    dec %i
  }
}

alias -l table.lookup {
  find.table
  return $hget(%myscript.tablename, $1)
}


Use $table.lookup() as your primary alias and it will ensure that the table variable is always set. This does make an assumption that you (a) only have one table at any time (you're deleting the others) or (b) if you do have multiple tables, the "last created" one is the "active" table. Of course you could also write the table name to a file to ensure you could reload it if variables were erased. That might be more efficient than $hget(N). Your call there.

- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"