Improve InStr or IfInString

Propose new features and changes
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Improve InStr or IfInString

16 Dec 2017, 15:30

Helgef wrote:]
The regex options ...) aren't part of the regex pattern, they are parsed and put aside, and correspond to certain option flags, which are bitwised combined to one option number, which is a pretty standard way of specify options for a function in many programming languages. For guis I think it would be reasonable to remove a lot of string options in favor of bit-wise combinations when defining styles for the guis. Methods and properties could set other options. (I'm thinking aloud, rather than making any definite claims on how things should be)
I don't think that using bitwise combinations in a language that doesn't have constants is a good idea.
Also RegExMatch is it's own thing from an external language. I have a few complains about it, however RegEx options are not needlessly complex when compared to jeeswgs inStr options.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

17 Dec 2017, 09:03

- @Helgef: You're right that using leading characters (before the first ')') in RegExMatch, is AHK specific, however, 'm' is a standard part of RegEx:
pcresyntax specification
http://www.pcre.org/original/doc/html/pcresyntax.html
(?m) multiline
- Returning an object would be OK, I would add an 'o' option to allow this.
- I currently use JEE_MX (if var in: exact match), JEE_MC (if var contains), JEE_StrMatch (all-purpose match function for other situations).
- I don't mind using a separate function, StrMatch, or amending InStr. However, I would probably end up discarding InStr entirely, because I like to be able to switch quickly from one needle to two needles.

Code: Select all

;e.g. proposal:
if InStr(vText, "a")
if InStr(vText, "a,b", "D,")

if StrMatch(vText, "a")
if StrMatch(vText, "a,b", "D,")
==================================================

- @nnnik: Ultimately, any points about autocomplete are irrelevant, autocomplete exists to save time, but changing one letter in a parameter, saves more time. Any functions suggested would be usable with autocomplete, just like any other function.
- Re. any potential concerns about readability in the options parameter, the main fix is to recommend using capital letters, as demonstrated below. But note: the readability issue applies to all sorts of functions e.g. MsgBox, InputBox, Sort, Loop, GUI functions/methods.
- 'I leave things out I consider common sense'. This is a dangerous and generally unwise thing to do in almost any industry. Not just regarding safety, it's a classic way to waste time, as it emerges that you shouldn't have left out the things you did. Also, who defines what is or isn't 'common sense'.
- You are welcome to comment on macro and micro layers, but please make your comments more specific. Also, remember, comments in the forum are for the benefit of everyone, not just me, so its better to express your points fully, than it is to hint at something but withhold information.
- Re. who or what is a programmer, or what they should know. I've produced some console and GUI apps in C++, I wouldn't recommend you to assume specific knowledge that all programmers know.
- Your point about checking the function name versus checking the parameter letter is a fair one. The solution is StrContains/StrExact for most purposes, and possibly StrStarts/StrEnds, and StrMatch for less common situations. Either way parameters for specifying the delimiter/case sensitivity/numeric comparison would still be necessary.
- Fundamentally it saves time, if you think through how people, not just me, will interpret your points, and aim for clarity and completeness. This is not meant to be unkind, but I generally find your posts to be the least clear on the forum, and when I translate posts from German to English, I still find your translated posts less clear than other people's translated posts. I have since found out though, that this is not because you are bad at expressing yourself, it is that you keep assuming that people know things and you keep omitting important details.
- I would be interested in your criticisms of RegEx.
- You said that my notation was more complicated than RegEx. In fact, I take this as a compliment. I did think that having roughly 10 options gave you something similar in scope to RegEx, but this is a good thing, I wanted an all-purpose string function, but that unlike RegEx, handled strings literally. The options are pretty straightforward though, similar to those of the Sort function.
- Generally when considering functions I look for very simple functions, that people are unlikely to object to, 'is this function the standard function that most people would produce'. For an all-purpose StrMatch function, similar to the Sort function, you have to be a bit creative, and offer a complete and novel package. I was quite prepared to hear objections to it, and/or amend my proposals accordingly. What is clear is that the issues I'm trying to address are important, and need to be addressed.

==================================================

- Note: in a post above, I've added the 'w' (within) option:

Code: Select all

if ("a" within "abc")
if ("abc" contains "a")

if ("a" within "abc,def,ghi")
if ("abc" contains "a,b,c,d,e,f,g,h,i")
- Here is a fundamental issue. For ease of use, you want to either change the parameter/function/operator, to switch between functionality.

Code: Select all

;examples: contains/in matches, with a custom delimiter (pipe)
;options as parameter 3 or 1 are demonstrated for each example

;change parameter (leading/trailing parameter) e.g. C to X
;note: 'StrMatch' could be 'InStr' instead
;verdict: good, easy to change one letter
if StrMatch(vText, vNeedle, "C D|")
if StrMatch(vText, vNeedle, "X D|")
if StrMatch("C D|", vText, vNeedle)
if StrMatch("X D|", vText, vNeedle)

;change function (leading/trailing parameter) e.g. Contains to Exact
;note: StrExact, because InStr/StrIn (contains/exact) would be confusing
;verdict: bad, you have to change more letters, you would need 6 or more functions, *and* you still need an options parameter to specify a custom delimiter/case sensitivity/numeric comparison
;verdict: proviso, I would consider 2 2-parameter no-options functions that mimic 'if var in/contains' (so 2 commonly used simpler functions, and then an all-purpose StrMatch function for everything else)
if StrContains(vText, vNeedle, "D|")
if StrExact(vText, vNeedle, "D|")
if StrContains("D|", vText, vNeedle)
if StrExact("D|", vText, vNeedle)

;change operator e.g. contains to in
;verdict, good, this is fine, however, users can make custom functions, but not custom operators
if (vText contains (vNeedle, "D|"))
if (vText in (vNeedle, "D|"))
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

17 Dec 2017, 09:26

One thing that feedback has definitely helped me to see is:
- The benefits of being able to distinguish contains/in based on the function name, rather than having to check the parameter for X (or no X) each time.
- And as a result of this, having very short function names would be a consideration for such commonly used functions, I use MX and MC (match exact/match contains).

One idea I came up with just now, is this:

Code: Select all

if (T = N)
if (T ~= N)
if (T op(MyOp) N)

;where:
MyOp := "MyOp"
(T op(MyOp) N)
;is equivalent to:
MyOp(T, N)
It might look quite novel, but since I like using =, ==, ~=, I would actually consider using this.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 20 guests