Is it possible to keep string processing syntax consistent？

[tuzi]

for example substr(),trim(),strsplit(),strreplace(), all string functions return the processed string, except RegExMatch() and RegExReplace().

It seems that V1 has compromised in order to maintain compatibility, but V2 has given up compatibility with v1. Why not unify their behavior?

[boiler]

RegExReplace() does return the processed string. There was discussion here regarding the suggestion to have RegExMatch return a match object instead of the found position.

[lexikos]

The non-RegEx equivalent of RegExMatch is InStr, which does not return a string either.

[nnnik]

Hey if we are at it I think StrLen should return a string too. \s

[vvhitevvizard]

@tuzi @lexikos @nnnik
IMHO regexmatch and instr return what is naturally expected (a found index within the string) but we might have their counterparts added to return a substring, too. Or add additional output var parameter to them. It would save CPU time and reduce script's code cuz in the majority of cases substr is following it anyways.

[tuzi]

@boiler
@lexikos
@nnnik
@vvhitevvizard
I have read the previous discussion, but I still adhere to my point.

The reason is that:

instr(), we pass in is a known string like "abc", so the expected result is the "abc" in or not in the Haystack, if in, retrun pos. if not in, return zero.

RegExMatch(), we pass in is a pattern like "\d+", so the expected result is the string that matches the pattern. not a pattern in or not in the Haystack.

Strlen(), we pass in is a known string like "abc",so we just want to get the length.

[swagfag]

Code: Select all

MsgBox % StrLen("hello world")
; => "eleven"

@nnnik was onto something

[vvhitevvizard]

RegExMatch(), we pass in is a pattern like "\d+", so the expected result is the string that matches the pattern. not a pattern in or not in the Haystack.

I do support ur point. I, for one, would like all that stuff to follow the same design rule.
Changing RegExMatch() to return substr or NULL (empty string) sounds reasonable. The command creates Match object to return position, length and so on for the found substrings

[boiler]

RegExMatch(), we pass in is a pattern like "\d+", so the expected result is the string that matches the pattern. not a pattern in or not in the Haystack.

The pattern is not always so simple, thus the result is not always a simple string. An object is used to capture the various aspects of the match (captured subpatterns, for example). In the thread I linked in my prior post, fincs suggested having it return the match object, and lexikos pointed out the reasons why he is not implementing that suggestion — largely for performance reasons.

[vvhitevvizard]

The pattern is not always so simple, thus the result is not always a simple string.

To return the whole string for simple patterns (=Match.Value(0)) or the first captured group inside () (=Match.Value(1)) or NULL (empty string) if none found.
It makes sense to have a simplified RegExMatch's counterpart (RegEx(Haystack, NeedleRegEx, Starting Pos) or something) that returns no Match object but just a substring - analogous to ~= shorthand that just returns a position or NULL.

[tuzi]

@boiler

I read the views of lexikos and fincs.
At first, I shared the same view with fincs that we should return the matching object directly.
But lexikos is right. Many times people want to use it simply, so the new view is that for simple use, use return value(string), and for complex cases, use matching objects.

When people get pos, they do two things most often.
1 is use pos to know pattern match or not match.
2 is use pos to get match string. Obviously, further processing is needed, such as getting the length or using the matching object.

if return string, we can handle two situations well.

In conclusion, my point is complex cases use matching objects, and simple cases use string instead of pos, because isolated pos are less useful than string.

[tuzi]

@vvhitevvizard
If we create three different RegExMatch() regex ~=, will it confuse people?

[lexikos]

RegExMatch(), we pass in is a pattern like "\d+", so the expected result is the string that matches the pattern.

The expected result is a value indicating whether the RegEx matches. If it returned the overall matched value, it would not be a boolean value, so statements such as if RegExMatch(haystack, pattern) would be unreliable. Patterns can match strings of zero digits or of zero length.

I need the position more often than the overall match, such as for repeated matching in a large string. If I need a matched value, it is usually a subpattern, not the overall match.

You can always write your own very simple function that adapts RegExMatch to whatever usage you want.

[vvhitevvizard]

@vvhitevvizard
If we create three different RegExMatch() regex ~=, will it confuse people?

Possibility to choose would confuse some.
But in general, having function's counterparts with slightly different in/out types and/or total params amount is common:
E.g. gdiplus\GdipFillRectangle accepting float coordinates and gdiplus\GdipFillRectangleI accepting integers,
kernel32\LoadLibrary accepting 1 parameter and kernel32\LoadLibraryEx accepting 3 parameters (including additional flags),
and so on, not to mention that there r A and W variants for many string accepting functions to distinguish ANSI from Unicode ones.

[nnnik]

Yes but those follow a commonly established convention.
For RegExMatch it would be completely random.
Nobody would expect the output parameter to change depending on the calling convention.

[_3D_]

Why string methods return integer?
1. Integer is most closer to boolean - so you can faster check the result.
2. Integer is most closer to cpu - so you get faster maintenance.
3. Integer is small enough - so result will lend less ram and or stack.

If you think about string as "abc" and result as "a" - yes string is better. But if your string is 10K and result is 8K then:
1. Result will lend double ram - and if you need just to check if(strmethod(...)) - ram will become highly fragmented.
2. If you use the result as argument - you will fill stack with unusual data or you must have special treatment of using string when argument (pass string as reference or pointer).

In AHK strmethods(...) have extra: return 0 if not - if result is string "" you don`t know is that the result or no coincidence.

In conclusion: result must be simple and unambiguous.