Regexmatches oddity noted

[Papoulka]

It's convenient that variables will often concatenate automatically with other symbols, especially in regex use. For one thing it makes the code much more readable. But I understand that this may not be a "guaranteed" behavior.

So ONLY in the interest of pointing out what MAY be unintended operation:

Code: Select all

/*
$tokn="X";
 $targ="_X_";
 echo regexmatches($targ, $tokn);
 echo regexmatches($targ, _$tokn);
 echo regexmatches($targ, $tokn_);
 

The point is that a leading "_" will concatenate OK for the regex, but a trailing underscore will not. In contrast, a trailing "\." does work. I can work around the issue with intermediate variables or full concatenation syntax. So just noting this.

[highend]

It happens because XY is very (imho: too) tolerate on how strings can be used

Code: Select all

_$tokn

XY interprets the "_" as a string. You should double quote + concatenate it to make this clear (or double quote both together)
E.g.:

Code: Select all

"_" . $tokn

Code: Select all

"_$tokn"

Code: Select all

$tokn_

This isn't interpreted as a string but a variable name!

Use

Code: Select all

$tokn . "_"

to get the correct result

Help file, Advanced Topics - Scripting - Variables - Format and Scope

[PeterH]

A bit further:
_$tokn in general is a syntax error (string "_" outside quotes) - but tolerated by XY.
But is reported when syntax check is on (ScriptStrictSyntax=1).

"_$tokn" is a variable prefixed by "_", while
"$tokn_" is the variable $tokn_

For me the first is a problem - the others are useful results of correct interpretation of syntax.

[Papoulka]

Thanks for the detailed replies, which explain things very clearly. I had forgotten the variable definition rules while buried in regex issues, and assumed this might be related to the latter.

Short-cut concatenation is very convenient but risky. I'll remember at least that much, going forward.