Forums Feature Suggestions $hget(0).name

Either numeric table names should be disallowed, or there should be a .name prop to be like $timer().name which returns $null if it exists or returns the Nth position of table named as that string.

//var -s %table $hget(0) + 2 | hadd -ms %table item value | echo -a does tablename %table exist: $hget(%table)

One scenario I can see this happening is when a tablename comes from $nopath(filename), where filenames 12345678 would create a table that $hget(string) thinks does not exist yet it does. Or filenames 0 or 1.234 could result in thinking that a table exists when it does not.

For $hget(N,1).item and $hget(N,1).data they should continue returning info about the 1st item of the Nth table in the list, and input could be sanitized to handle numeric tablenames by doing $hget($hget(N).name,1).item

Update:

Though $hget could benefit from $hget(string).name to force it to always "Returns name of a hash table if it exists", the other $hget syntax doesn't handle numeric tablenames gracefully. While /hdel and /hadd correctly add and remove items from numeric tables, and /hfree 2 deletes the table named 2, the other hashtable identifiers do not handle numeric tablenames correctly.

Now:

$hget(2,1).item = 1st item of whatever is the 2nd tablename
$hget(2,string) = value of itemname=string in whatever is the 2nd tablename

$hget(0,1).item = ignores the 2nd parm and the .item property and always returns the number of tables
$hget(0,string) = ditto

//echo -a $hfind(2,*,0,w,echo -a $1) = lists all the items in whatever is the 2nd tablename

--

These identifiers could be handled by giving $hget an extra parm for switches that would force the 1st parm to be seen as a tablename, and giving the existing $hfind switch list an extra parm.

Assuming the new switch an arbitrary 'X'

For numeric tablename '2', it would still need .name to check for the table's existence, because $hget(2,X) would crash with current syntax which gets the value of itemname=X from the 2nd table in the list.

However $hget(2,itemname,X) could get the value of itemname from tablename=2, and $hget(0,itemname,X) would then look at the numeric tablename too. Or, instead of $hget(2).name to see if tablename=2 exists, it could avoid a new properity $hget(2).name when parm2 exists as null, $hget(2,,X) instead of adding $hget(2).name

The only problem I can see for $hget is that since existing syntax currently uses the 3rd parm only to hold the name of a &binvar, it would need to assume that parm3 beginning with & does not hold any switches so there would be no support for loading a &binvar from a numeric table - or else the switches would need to be in parm4.

--

For $hfind, $hfind(2,*,0,wX,echo -a $1) would force the 1st parm to be seen as a tablename.

Since $hfind already has the 'n' switch which behaves the same regardless whether using 'n' or 'N', maybe the new switch would be something like 't' that could be used with the same meaning for both identifiers?