From WikiChip
Difference between revisions of "mirc/identifiers/$~"
< mirc‎ | identifiers

(Created page with "{{mirc title|$~ Identifier}}'''$~''' is a construct which allows you to call a built-in identifier while both bypassing custom identifier in their absence, and avoiding the id...")
 
 
Line 1: Line 1:
{{mirc title|$~ Identifier}}'''$~''' is a construct which allows you to call a built-in identifier while both bypassing custom identifier in their absence, and avoiding the identifier warning. Returns $null in versions where the name doesn't exist as a built-in identifier.
+
{{mirc title|$~ Identifier}}'''$~''' is a construct which allows you to call built-in identifiers only, custom aliases are not checked. This conveniently avoids the identifier warning message and halting behavior. Returns the result of the built-in identifier call, or $null (see the notes)
 
 
Note: This is recommended on the {{mirc|optimization}} page to enhance speed of scripts.
 
  
 
== Synopsis ==
 
== Synopsis ==
<pre>$~</pre>
+
<pre>$~identifiername()</pre>
  
 
== Parameters ==
 
== Parameters ==
 
None
 
None
== Examples ==
+
== Notes & Examples ==
 +
 
 +
It's unclear still why this undocumented construct exists. Khaled stated that this should not be used in scripts, that it changes the way the paramater are parsed. But a look at a decompiled mirc.exe says otherwise, the only thing it does is prevent custom aliases from being checked.
 +
 
 +
As a result, the identifier warning message is not triggered and the script not halted if you call an identifier that is not a built-in identifier of mIRC.
 +
 
 +
This can effectively be used to check for existence of a built-in identifier, be it if you want to do something once a future version has the identifier, or if you want to support older mirc version not having a built-in identifier. This has recently proven to be useful to write mIRC/Adiirc compatible script.
 +
 
 
<source lang="mIRC">
 
<source lang="mIRC">
Using $~ has no change in behavior in versions where the build-in $rands identifier exists. However, in prior versions the usage of $~ prevents calling a custom identifier, as would happen for the 2nd identifier call:
+
 
 
//echo -a $~rands(1,6) vs $rands(1,6)
 
//echo -a $~rands(1,6) vs $rands(1,6)
  
The $~ avoids the script being halted due to an identifier warning:
+
if ($~rands(1,1) == 1) { echo -sg this version support $!rands }
//echo -a $~no_such_identifier
+
 
 
</source>
 
</source>
  
Note: While this has been known about and used for over 15 years, only recently has it been stated that this is intended for internal mIRC use and should not be used in scripts. For that reason, it's not likely that the bug related to spaces handling would be fixed.
+
However, recently it was figured out that $~ have a purpose that makes more sense, and that's local identifiers, one that only have a value in specific mIRC events.
 +
Because such identifier have a global scope, they have a value inside an alias if that alias is called from the event's scope.
 +
So consider for example a script that's going to be shared on different mIRC configuration/install/machine:
  
1. You MUST avoid having spaces inside the parameters area. In this example, the spaces causes the strings not touching the $~ to be displayed:
+
<source lang="mIRC">
<source lang="mIRC">//echo -a $~null(abc, def , ghi)
+
on *:text:*:#:process_message $1-
returns: def , ghi)
+
on *:input:#:processs_message $1-
//echo -a string: $~null(abc,def,ghi)
+
alias process_message {
returns: $null
+
var %nick $iif($nick,$nick,$me)
 +
....
 +
}
 
</source>
 
</source>
2. The spaces also determines whether identifiers used as parameters are evaluated. In this example, repeating this command shows that $regml(foo,2) executes even when it's inside an identifier that doesn't execute, $regml(foo,1) does not get updated until inserting a space preceding $ of the first $regex. Removing all internal spaces avoids both $regex from evaluating:
+
which is typical, if you load this script into a mIRC which has a custom alias named "me" returning "test" for example, this script would fail, %nick would incorrectly take the value "test" for your on input. This is where $~ is useful, using $~nick would actually ensure that if $nick has a value, then this value can only come from the event specific identifier and never a custom aliases, indeed preventing conflicts.
 +
 
 +
Another thing to consider is the spacing, if the $~identifier call is not a built-in and you have some spacing, consider:
 +
 
 
<source lang="mIRC">
 
<source lang="mIRC">
//echo -a foo1: $regml(foo1,1) foo2: $regml(foo2,1) | echo -a text: $~nosuchidentifier( $regex(foo1,$r(a,z),/(.)/) , $regex(foo2,$r(a,z),/(.)/) ) foo1: $regml(foo1,1) foo2: $regml(foo2,1)
+
echo -ag $~nonbuilt-in( $me )
 +
;displays "yournickname )"
 
</source>
 
</source>
 +
in this case only the part up to the space is evaluated as $null, the rest of the line is not touched and will evaluate normally.
 +
 +
This means that to correctly check if an identifier is supported, you must not use space:
 +
 +
<source lang="mIRC">
 +
if ($~rands(1,1) == 1) { echo -sg this version support $!rands } // correct
 +
if ($~rands(1, 1) == 1) { echo -sg this version support $!rands } // incorrect
 +
</source>
 +
as it will now act as 'if ( 1) == 1)' on a version not supporting $rands, instead of 'if ($null == 1)'
  
 
== Compatibility ==
 
== Compatibility ==
Version added: TBD
+
Version added: 6.0
  
 
== See Also ==
 
== See Also ==
{{mirc|optimization}}
 

Latest revision as of 05:48, 23 February 2023

$~ is a construct which allows you to call built-in identifiers only, custom aliases are not checked. This conveniently avoids the identifier warning message and halting behavior. Returns the result of the built-in identifier call, or $null (see the notes)

Synopsis[edit]

$~identifiername()

Parameters[edit]

None

Notes & Examples[edit]

It's unclear still why this undocumented construct exists. Khaled stated that this should not be used in scripts, that it changes the way the paramater are parsed. But a look at a decompiled mirc.exe says otherwise, the only thing it does is prevent custom aliases from being checked.

As a result, the identifier warning message is not triggered and the script not halted if you call an identifier that is not a built-in identifier of mIRC.

This can effectively be used to check for existence of a built-in identifier, be it if you want to do something once a future version has the identifier, or if you want to support older mirc version not having a built-in identifier. This has recently proven to be useful to write mIRC/Adiirc compatible script.

//echo -a $~rands(1,6) vs $rands(1,6)
 
if ($~rands(1,1) == 1) { echo -sg this version support $!rands }

However, recently it was figured out that $~ have a purpose that makes more sense, and that's local identifiers, one that only have a value in specific mIRC events. Because such identifier have a global scope, they have a value inside an alias if that alias is called from the event's scope. So consider for example a script that's going to be shared on different mIRC configuration/install/machine:

on *:text:*:#:process_message $1-
on *:input:#:processs_message $1-
alias process_message {
var %nick $iif($nick,$nick,$me)
....
}

which is typical, if you load this script into a mIRC which has a custom alias named "me" returning "test" for example, this script would fail, %nick would incorrectly take the value "test" for your on input. This is where $~ is useful, using $~nick would actually ensure that if $nick has a value, then this value can only come from the event specific identifier and never a custom aliases, indeed preventing conflicts.

Another thing to consider is the spacing, if the $~identifier call is not a built-in and you have some spacing, consider:

echo -ag $~nonbuilt-in( $me )
;displays "yournickname )"

in this case only the part up to the space is evaluated as $null, the rest of the line is not touched and will evaluate normally.

This means that to correctly check if an identifier is supported, you must not use space:

if ($~rands(1,1) == 1) { echo -sg this version support $!rands } // correct
if ($~rands(1, 1) == 1) { echo -sg this version support $!rands } // incorrect

as it will now act as 'if ( 1) == 1)' on a version not supporting $rands, instead of 'if ($null == 1)'

Compatibility[edit]

Version added: 6.0

See Also[edit]