mIRC Home    About    Download    Register    News    Help

Print Thread
New ID property for IAL entries #260014 19/02/17 03:35 AM
Joined: Feb 2003
Posts: 2,782
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,782
Dear Khaled,

I have a lot of want for added features to the IAL, but there is one very small feature that would make a world of difference, I think. Exposing a unique ID for each IAL entry so they can be referenced via hash table and variables. If someone disappears and reappears from the IAL, they'd naturally acquire a new IAL().ID. These IDs should be unique across all $cid's and should not be recycled until mIRC closes.

I understand that information can be stored against the IAL via /ialmark, but this is the only such slot for storing information and it's easily destroyed and conflicted by other scripts.

My feature creep extra request would be the ability to store multiple named ialmarks, via /ialmark <nick|@ID> <item> <text> or a newly named command (though IAL IDs would help with hashtable entries). $ial(@ID) might retrieve records across CIDs the same way @$wid does for $window() commands.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: New ID property for IAL entries [Re: Raccoon] #260058 24/02/17 05:10 PM
Joined: Feb 2003
Posts: 2,782
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,782
Thank you! mIRC v7.47.638 Beta


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: New ID property for IAL entries [Re: Raccoon] #260067 25/02/17 11:07 AM
Joined: Dec 2002
Posts: 5,003
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,003
As this required important changes to the IAL, it affects all of the IAL commands/identifiers, so it needs heavy testing to make sure it is working correctly. If you spot anything odd, please let me know :-)

Re: New ID property for IAL entries [Re: Khaled] #260077 25/02/17 06:09 PM
Joined: Feb 2003
Posts: 2,782
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,782
Code:
27.Extended /ialmark to allow setting arbitrary marks using the format:

   /ialmark -nr <nick> [name] [text]

   -n = the [name] of the mark. If -n is not used, the default name
   'mark' is used.

   -r = remove the mark

   Marks can be accessed using $ialmark(nick,N/mark) and properties
   'mark' and 'value'.


Ok, so, out of the gate, I'm not sure when or where the '.mark' property is meant to be used. It seems to me that $ialmark() without a property will always behave as if the '.mark' property is used with it.

Can these new marks be used with regular $ial() and with $ialchan() ?

Only unusual behavior I see so far is $ialmark(Raccoon) without N specified will behave as if N = 1. (and as if the .mark property is used, of course.)

Could you elaborate a little more about this design, and I'll try to break all of those aspects you describe.

Here's some test examples:

/ialmark -n Raccoon server cards.freenode.net
/ialmark -n Raccoon joined.#mIRC 1488047314
/ialmark -n Raccoon spoke.#mIRC 1488047485

Behaviors I observe:

$ialmark(Raccoon,0) == 3 (good)
$ialmark(Raccoon,1) == server (good. 'N' implies .mark)
$ialmark(Raccoon,1).value == cards.freenode.net (good)
$ialmark(Raccoon,1).mark == server (ok. good.)
$ialmark(Raccoon,server) == server (redundant? expected implied .value, same as $hget()?)
$ialmark(Raccoon,server).value == cards.freenode.net (ok. but shouldn't require .value)
$ialmark(Raccoon,server).mark == server (ok. good.)
$ialmark(Raccoon) == server (odd.)
$ialmark(awyhtlwjfkuihsfelk) == $null (good.)

Behavior I would expect:

$ialmark(Raccoon,server) == cards.freenode.net

$ialmark(Raccoon) == should be Raccoon(?) or the value of default unnamed mark (no -n switch used)?
* Being a hash list, the mark N=1 will change as more mark names are added and shuffle around the internal hashlist.

Request:

/ialmark -nrw Raccoon *
/ialmark -nrw Raccoon joined.*

Notes:

I can't find a specific use case for the $ialmark().mark property since it is always implied. The $ialmark().value property could be useful if a mark name is itself a numeric value.
* Update: Wims points out that .mark can be used to verify an item is really an item. if ($ialmark(Raccoon,server).mark) { exists }

Last edited by Raccoon; 25/02/17 09:14 PM.

Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: New ID property for IAL entries [Re: Raccoon] #260082 26/02/17 08:31 AM
Joined: Dec 2002
Posts: 5,003
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,003
Quote:
Can these new marks be used with regular $ial() and with $ialchan() ?

$ialmark() is used to access the mark list that you create for each $ial() nickname.

Quote:
$ialmark(Raccoon,server) == server (redundant? expected implied .value, same as $hget()?)

This allows you to check if it exists.

Quote:
$ialmark(Raccoon) == server (odd.)

This returns the first mark, N = 1, which is how most identifiers work if no N is specified.

Quote:
I can't find a specific use case for the $ialmark().mark property since it is always implied.

It is there for completeness.

Quote:
The $ialmark().value property could be useful if a mark name is itself a numeric value.

The $ialmark() design precludes mark names that are numbers since there needs to be a way to iterate using N.

That said, the property names are definitely not right, ie. for consistency, $ialmark() should be using ".name" to match /ialmark -n [name] and ".mark" to return the mark value, same as $ial().mark. This will be in the next beta.

Re: New ID property for IAL entries [Re: Khaled] #260084 26/02/17 10:41 AM
Joined: Feb 2003
Posts: 2,782
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,782
If you settle on .name instead of .mark, then I would recommend changing $ial().name to $ial().realname or $ial().gecos

To me, it still feels like .mark (or .name) should be the default behavior UNLESS a non-numeric string is passed for $2. Then, it should behave as if .value property was used. That would feel natural, anyway, like $hget(Raccoon,server).

Also, $hget(Raccoon) == Raccoon, and not whatever happens to be $hget(Raccoon,1).item (arbitrarily random hash item). But $ialmark(Raccoon) should probably return the default mark set without '-n', aka: '/ialmark Raccoon Typical pre-beta unnamed mark'

Last edited by Raccoon; 26/02/17 10:50 AM.

Well. At least I won lunch.
Good philosophy, see good in bad, I like!