NumOp/StrOp (with respect to !=/!==)

Discuss the future of the AutoHotkey language
User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

NumOp/StrOp (with respect to !=/!==)

13 Aug 2018, 14:09

- I've noticed a lot of suggestions here re. changing string/number handling.
Pull Requests · Lexikos/AutoHotkey_L · GitHub
https://github.com/Lexikos/AutoHotkey_L/pulls
- I welcome the != change, as now (var1 != var2) and !(var = var2) are consistent. However, one side effect is that !(var1 != var2), dependent on A_StringCaseSense, is no longer available, with no good alternative at present.

- I thought that the following might be useful:

Code: Select all

NumOp(op, var) ;unary (2 params)
NumOp(var1, op, var2) ;binary (3 params)
NumOp(var1, op1, var2, op2, var3) ;ternary (5 params)

StrOp(op, var) ;unary (2 params)
StrOp(var1, op, var2) ;binary (3 params)
StrOp(var1, op1, var2, op2, var3) ;ternary (5 params)

;e.g.
NumOp(var1, ">=", var2, "<=", var3) ;ternary (numeric between)
StrOp(var1, ">=", var2, "<=", var3) ;ternary (string between)
- And potentially something like this:

Code: Select all

result := (var1 Op(vOpName) var2)
- Btw should Integer("abc") return 0? And Float("abc") return 0.0?
- The way I see it, we mainly need an IsNum (looks numeric) function, prior to (or instead of) using Integer and Float. And scripts should not normally be expecting possible errors, which then need to be handled.

- Also I'm a little concerned that something as fundamental as string/number handling in expressions is being dealt with in a cavalier/backdoor way via GitHub 'Pull Requests', instead of receiving the full attention and scrutiny of the AutoHotkey v2 Development forum.
- I think that the AHK v1 behaviour was fine, it was very practical and convenient, a strength of AutoHotkey. If people object to the use of "" var or var+0, perhaps functions should be available to guarantee the desired behaviour, and present it in a tidy way. Hence my suggestions above.
- While some people's suggestions are potentially increasing consistencies in some areas, they are also creating new problems, such as potentially preventing string comparisons via operators, and the sum of those changes could be quite a lot worse than what we had in AHK v1.
- Anyhow, I'd rather see people lay out a complete and consistent vision of the way forward, rather than a drip feed of source code suggestions.
Helgef
Posts: 3232
Joined: 17 Jul 2016, 01:02
Contact:

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 11:48

However, one side effect is that !(var1 != var2), dependent on A_StringCaseSense, is no longer available, with no good alternative at present.
AutoHotkey v2 aims to improve the usability and convenience of the language
src
Non-sensical operator games are not very usable or convenient, and also not readable, predictable or modular. If you want the equality condition to be readable, predictable and modular, use a compare function, which in v2 is very convenient to implement via nested functions / closures / fat arrows. And it is much more flexible, hence, much more usable.
Btw should Integer("abc") return 0? And Float("abc") return 0.0?
No, for the same reason it shouldn't return 37, abc not a number.
The way I see it, we mainly need an IsNum (looks numeric) function
x [url=https://lexikos.github.io/v2/docs/commands/is.htm]is[/url] 'number'
I think that the AHK v1 behaviour was fine
You should stick to it then.
While some people's suggestions are potentially increasing consistencies in some areas, they are also creating new problems, such as potentially preventing string comparisons via operators, and the sum of those changes could be quite a lot worse than what we had in AHK v1.
Some people's inability to understand these operators potentially resulted in the suggested changes.
Also I'm a little concerned that something as fundamental as string/number handling in expressions is being dealt with in a cavalier/backdoor way via GitHub 'Pull Requests', instead of receiving the full attention and scrutiny of the AutoHotkey v2 Development forum.
backdoor? :lol: :facepalm:

Cheers.
guest3456
Posts: 2434
Joined: 09 Oct 2013, 10:31

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 17:31

Helgef :thumbup:

lol at calling github PR's "backdoor". it's literally the exact opposite

jeeswg, are you taking note about the stuff we talked about in the past?

User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 19:40

- @Helgef: I had thought that 'stricter' type handling for expressions might have some advantages, as well as some disadvantages.
- Looking at the drip feed of GitHub pull requests, I now see further disadvantages, which may (or may not) be soluble if discussed properly.
- I think this topic needs respect. If you want to overhaul the fundamentals of expressions and operators, in my view, you should outline the proposals in full, in one place. The before and after details. And at least some cost-benefit analysis details/considerations regarding updating old scripts.
- And yes, this link, which I'd forgotten about, is, to some extent, a good template.
passing parameters as strings v. numeric - Page 4 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 81#p211881

- (On balance, I've found the AHK v1 behaviour increasingly advantageous, as I've compared the pros and cons of various proposals. It allows brevity through smart assumptions and it allows full control where desired. It allows you to not worry about types, an AHK hallmark, while also allowing you to force numeric/string comparisons.)
- (Also, I have simply never found the AHK v1 behaviour to be a problem.)

- I suppose that 'Integer' and 'Float' look like mathematical functions, and 'error' is common for mathematical functions. (Although, in reality they are more like type/format/conversion functions. If you convert a string to a number, e.g. for sorting a list numerically, 0 is a good candidate. But yes, the 'look mathematical' point wins out I suppose.)
compare function, which in v2 is very convenient to implement via nested functions / closures / fat arrows.
- I don't know what you mean, perhaps you could clarify. You suggested a built-in function, built-in functions don't have to be implemented by the user.

- @guest3456: You can message me, that's fine.
- I don't know how many people even know that AutoHotkey is on GitHub. (I didn't know this for many years. I was hardly aware of GitHub for many years.)
- Everything is 'backdoor' on GitHub anyway, it's so hard to find anything.
- E.g. with != and !==, even though I agreed with those changes, it would have been beneficial to have them mentioned in a more prominent place, to avoid various code rewrites which I have now done.
- What other places should we be aware of? Is GitHub officially mentioned on the AHK forums, or in the documentation? Even when you know they exist on GitHub, these random discussions can be hard to find, cf. a proper thread on the AHK forums. (And how well are the GitHub discussions indexed on Google/Bing etc.)
coffee
Posts: 76
Joined: 01 Apr 2017, 07:55

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 20:57

If you want to overhaul the fundamentals of expressions and operators, in my view, you should outline the proposals in full, in one place. The before and after details. And at least some cost-benefit analysis details/considerations regarding updating old scripts.
Nobody has to do that, or pass anything by anyone, or seek permission of anyone, much less you. They only have to abide by the license, and the GPL well, good luck demanding cost-benefit analysis or trying to put red tape on it. If the one receiving the pull request doesn't like, doesn't want to merge anything, then it doesn't get merged. Opposite? then it gets merged.
- I don't know how many people even know that AutoHotkey is on GitHub. (I didn't know this for many years. I was hardly aware of GitHub for many years.)
How is that anyone's problem? If you want to get involved, even if it's just tracking changes and that's it, it doesn't take much effort if you actually spend a little bit of time reading where to and how to.
If you can't find the source, it's because you don't want to find it, or don't want to get involved.
- Everything is 'backdoor' on GitHub anyway, it's so hard to find anything.
Yes, that's why github, bitbucket, sourceforge, gitlab any other VCS is barren and not used at all, because it's "backdoor". You have to be really out of touch with reality to consider version control "backdoor". Everyone just uses notepad and acronis true image, apparently.
You clearly don't to want do anything at all.
- What other places should we be aware of? Is GitHub officially mentioned on the AHK forums, or in the documentation? Even when you know they exist on GitHub, these random discussions can be hard to find, cf. a proper thread on the AHK forums. (And how well are the GitHub discussions indexed on Google/Bing etc.)
Home page states where the source is located if you read past the hero image. There's a link in the downloads page, that drops right into it, pretty hard to miss unless you are blind and dont have text to speech/braile. Nobody has to publish or request permission if they want to upload the source to a github alternative and work there. You don't want to read, you don't want to find anything. You don't like when people reply harshly, but jesus christ man come on, get out of your comfort zone every once in a while and be a little more proactive and independent.

In documentation, v2 docs, straight through: https://lexikos.github.io/v2/docs/AutoHotkey.htm. Press on the pencil on v1. By then, you would have been exposed to the documentation in the home page, and in the downloads page.
The source is far from hidden, if you are still that dense and can't find the source, READ THE LICENSE FILE. What's GPL? search what's GPL, source nowhere and you downloaded a binary file from the dev's site? ask the developer to abide by the license and give you the link or the files. P-r-o-a-c-t-i-v-i-t-y.

It is no one's problem that you didn't know that, it is nobody's problem you don't want to go to github to discuss anything, or see anything or track anything or see how things are done, learn from it to replicate. Anyone who makes changes has 0 reason, 0 responsibility, 0 mandate to come here and post anything about any of the changes or pull requests they want to make. Ultimately, lexikos merges into his repo what he wants to merge, does what he wants to do, does it when he wants to do it, like anyone else would on these kinds of projects. Autohotkey_l is lexiko's autohotkey. Helgef has his own repo, nnnik has his own repo, along with the countless other forks that may or may not be active. You can see their changes, what they are trying to do, what they have done. I think you still haven't realized that AutoHotkey literally has no totalitarian owner, only a branch sponsored/backed by this website. Look at autohotkey_h, he could just as simply prop up his own forum separate from here as long as he abides by the GPL, does hotkeyit feel like its worth his time doing so? probably not.
If I want to make a pull request for Helgef, I will make the pull request to him and discuss with him, I don't have to discuss this with anyone else, anyone is free to jump in if they want if is a public repo. If he feels like it should be discussed with the public, he can either talk with whomever he wants to talk to or ask me to do it, then I can either make it public, or shrug it off and go on my merry way. If lexikos likes changes, sees they fit his wish for autohotkey and his schedule, then he merges. Denied/closed requests are not showstoppers to the person making them, they will continue to work in the fork of whomever made the pull public.
User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 21:59

- These kind of changes, re. types, could have the highest rewrite costs of any changes suggested so far, they are as serious as they get. Maybe you don't have too many scripts to maintain, or that you intend to share with other people.
- When I have wanted to propose important changes, but where the implementation specifics are either debatable or have major script rewrite costs, I try to be open and explicit about the drawbacks, and I court feedback. To me that's common courtesy. That's not to say that anyone else was being deliberately discourteous.
- Perhaps the utility of type flexibility trumps any supposed advantages of type restrictiveness. We can't have the full debate without the full facts.
OT
guest3456
Posts: 2434
Joined: 09 Oct 2013, 10:31

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 22:14

- @guest3456: You can message me, that's fine.
its not about messaging you. months ago, i said it was YOU who is out of touch with everything, with community etiquette, your post formats, and just being disagreeable in general. you PMed me saying that i am always "harsh" towards you.

but look again here. two more independent posters, Helgef and coffee, both very respectable and knowlegeable members, also seem to be trying to get you to relent and see the light. Helgef, being subtle about it, coffee a little more blunt. and with every response you post, you continue to fight them.

i could be even more blunt, like i have in the past, but its unlikely you will get the message, and instead just blame me for not being nice.
Last edited by guest3456 on 14 Aug 2018, 22:18, edited 1 time in total.

User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 22:17

You and coffee both have a 'certain style'.
guest3456
Posts: 2434
Joined: 09 Oct 2013, 10:31

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 22:18

You and coffee both have a 'certain style'.
yep, its always everyone else. blame everyone else. never look in the mirror.

thats your style

User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

14 Aug 2018, 22:28

- The idea of disabling the ability of certain operators to handle strings has come as a surprise. I thought the whole point of the String function was to facilitate the use of such operators.
Adding function StrCompare and disabling string compairsion of operators: < <= > >= by HelgeffegleH · Pull Request #107 · Lexikos/AutoHotkey_L · GitHub
https://github.com/Lexikos/AutoHotkey_L/pull/107
- I believe the idea of changing type handling, which I initially contemplated but am now less sympathetic to, was that if you define var := 1, it would always be considered numeric, and couldn't be compared against a string unless converted via String().
- (Without having the full picture of intended changes, it's difficult to know what the problems are and then how to solve them if possible.)
- (There are a few things I can say based on what I do know ...)

- I would recommend the following functions:
- IsNum: if var is "number" is too verbose, especially for multiple variables.
- Num: if it looks like an integer, make it an integer type, likewise for floats. Would Float be frequently used where Num might be more efficient and more descriptive.
- Str instead of 'String' ('String' is too verbose).
- Integer already exists (or perhaps Int).
- Float already exists.

- Str would be a neater alternative to "" var.
- Num would be a neater alternative to var + 0.

- Here are some demonstrations of decreasing verboseness.

Code: Select all

;ADDITION

;==================================================

if !(var1 is "number") || !(var2 is "number")
	return
if (var1 is "float") || (var2 is "float")
	var3 := Float(var1) + Float(var2)
else
	var3 := Integer(var1) + Integer(var2)

;==================================================

if !IsNum(var1) || !IsNum(var2)
	return
var3 := Num(var1) + Num(var2)

;==================================================

try var3 := Num(var1) + Num(var2)
catch
	return

;==================================================

;AFAIK, under certain proposals, this would fail in AHK v2 if either one was a string
try var3 := var1 + var2
catch
	return

;==================================================

;COMPARISON

;==================================================

if !(var1 is "number") || !(var2 is "number")
	return
var3 := Float(var1) < Float(var2)

;==================================================

if !IsNum(var1) || !IsNum(var2)
	return
var3 := Num(var1) < Num(var2)

;==================================================

try var3 := Num(var1) < Num(var2)
catch
	return

;==================================================

;AFAIK, under certain proposals, this would fail in AHK v2 if either one was a string
try var3 := var1+0 < var2+0
catch
	return

;==================================================
- I've seen differing proposals for how AHK v2 should handle strings/numbers in expressions. I was potentially interested in the stricter approach. However, I feel that people may incorrectly view the stricter approach as 'more natural' or simpler for detecting bugs, whereas actually, the more flexible AHK v1 approach may be the more intelligent, less verbose, and more readable option, and perhaps users should consider the original wisdom of the early decisions.
- If people prefer the stricter approach, they could use Str() and Num() functions throughout their script, instead of imposing awkward unhelpful restrictions on the rest of us.
OT
Last edited by jeeswg on 15 Aug 2018, 01:10, edited 1 time in total.
User avatar
nnnik
Posts: 3469
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 01:02

jeeswg its not important how many people know it.
The official place of the AutoHotkey source is github.
It is the official place to discuss it (even more official than this forum).

As it says for AHK v2 scripts may break once the next update comes.
And lexikos does write down when the next update comes.

I will continue making pull requests over there without further discussion here when I feel like it.
I just dont feel like making pull requests before lexikos approves the idea - (I dont particulary like doing work that does not get approved)

You need to understand thta AutoHotkey is a langauage that is essentially maintained and controlled by a single person - lexikos.
It's neither his job nor does he get paid for it. That means that we have a limited amount of work that can be done by him and that we are dependant upon his motivation.
Helgef added a lot of pull requests recently and really started contributing - unlike me (since i got side tracked by the whole neural network stuff).
Simply put what I want to say we have a limited workforce and a lot that needs to be done.
Under such conditions your opinion doesn't matter much unless you have someone that implements it for you.
Or simply put the work you o matters more than the things you tell other people to do.
Everyone can probably find something they can improve if they look a little to the side - but someone that actually picks it up and carries it is way more important.
Recommends AHK Studio
User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 01:33

- @nnnik: Thanks for your comments.
- (Just for the record, coffee and nnnik have stated some really obvious things that I already knew. Although clarity for a wider readership is good.)
- I never wanted to or tried to dictate how people should use GitHub, nor did I complain about the other 100 pull requests. However, I did start to notice a trend of important posts, including some of the most interesting posts I've seen, getting buried in GitHub.
- Also, the way posts get split up, it makes it harder to keep discussions readable, in one place.
- (And, is it not quite fiddly to take a request by someone that you 90% approve of, and perfect it. If so, do we not risk slowing down adding code, and decreasing the quality of code.)

FACILITATING PULL REQUESTS
- I have been preparing initial content for outlining the structure of the AutoHotkey source code. And a C++ beginner tutorial, which I will use as the basis for an AHK beginner tutorial.
- I hope, by asking (a few) questions, and building up the material, that we could have a good team of people who could write good source code.
- My intention would be to discuss such code on an AHK C++ subforum (in the Other Programming Languages forum for now), and then it could be submitted as a pull request, or lexikos could use it directly.
- Creating a short style guide and a few pointers could be helpful, to make the code more to lexikos's liking.
- If lexikos wanted, we could do some of the donkeywork towards AHK v2 features that have already been outlined.
- Otherwise I, for example, could focus on implementing all of my wish list requests in C++ code, in the knowledge that none of them might ever be added. But that anything that lexikos did like, the code would be mostly or fully ready to be added. And also, such code could be used towards features that were wanted, or as useful demonstrations to teach how to code C++ in the AHK style.

- I have written a StrRept function in C++ as a test, that I intend to share. You only have to make changes to the source code in 3 places btw.
- I also compiled a custom version of the AHK exe, having made 2 source code changes, that gives an InputBox with size 18 fonts.
- The AHK source code style is quite unlike other C++ code I've worked on. AFAIK you can't use std::string/std::wstring for example, or std::cout/std::wcout. How do you print, other than via MessageBox I might ask.
- I think that Sum and Product functions would be a good test. Similar to the Min/Max functions. Although I did not intend to propose such functions be added to AutoHotkey.
- Other ideas:
[Feature Request] Add "Sign" function - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 19#p233719
Wish List 2.0 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 13&t=36789
User avatar
nnnik
Posts: 3469
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 02:01

Being able to maintain a discussion here is just extra work.
Extra work people are doing that keeps them from changing the source for the better.
Extra work to maintain a discussion with the only purpose to notify people of "I did a thing" and "lexikos might like it too so things might change"?
I don't think that discussion here is worth it.

There is no complete agreement on the source - there is no 90% - you can always make things better whether its your own code or that of someone else.
For AHK v2 it's enough that the front end works. What stands behind it can be changed at a later date. In this case your 90% agreement are more than 40% enough to make things better.
And no it's not fiddly to accept pull requests and we do not risk slowing things down. That thought never occured to me and seems wildly out of touch.
If the PR is good accept it - if its not don't make it.
If anything the discussion is more likely to keep us from progressing.

I also agree that lexikos could push more donkey work on this community.
I think there are enough points to make out what could be done in his eyes - but to be frank I don't have the energy to combine them to get the picture and make a few "guess" PRs.
Regardless I think that source code discussions should happen on github.
Recommends AHK Studio
User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 02:10

- I could imagine a forum, with one proposed function or group of functions per thread.
- The OP takes responsibility for the finished function, although they may seed responsibility (and possibly retrieve it at a later date) if they feel someone else could do a better job.
- Not everything needs 'discussion'. But what I imagined was. I submit version 1. Some people make some suggestions. I submit my final version.
- Or. An additional first step. I ask for a few things to get me started.
- If I was accepting source code from someone else, I would probably want to tweak a few things, possibly just to make it fit within my style guide stipulations. So I'm curious, what's the best way to do this. GitHub, AHK forum posts, something else. My instinct is AHK forum posts. So, whatever the GitHub PR was, I'd probably want to amend it somewhat. Cheers.
User avatar
nnnik
Posts: 3469
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 02:20

- Not everything needs 'discussion'. But what I imagined was. I submit version 1. Some people make some suggestions. I submit my final version.
Thats how we use PRs right now.
If I was accepting source code from someone else, I would probably want to tweak a few things, possibly just to make it fit within my style guide stipulations. So I'm curious, what's the best way to do this. GitHub, AHK forum posts, something else. My instinct is AHK forum posts. So whatever the GitHub PR was, I'd probably want to amend it somewhat. Cheers.
Github PRs allow you to comment and discuss them - and even ask for the changes you want.
The OP takes responsibility for the finished function, although they may seed responsibility (and possibly retrieve it at later date) if they feel someone else could do a better job.
You could ask someone else to modify your fork of the AutoHotkey fork and accept their pull request into your fork before pull requesting into the original source.

Github is meant for discussion and contribution for source code.
This forum isn't. It's easy to figure out where to discuss this.
You should try github - it's not that difficult.

Gaining a general opinion is something very difficult.
It's also pointless since in the end only lexikos opinion matters.

Generally I consider operators with parameters an abomination and feel that methods or functions are the better option.
Recommends AHK Studio
User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 02:27

- OK, well, you seem to like GitHub PRs. Since some of what I intend to do, would be inappropriate as GitHub PRs, I can at least give my approach a try to begin with.
- Btw I don't recall anyone saying anything about operators with parameters. What are you referring to? StrOp and NumOp would be standard functions. And for var1 MyCustomOp1 var2, that would be a standard operator. Thanks.
User avatar
nnnik
Posts: 3469
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 02:34

Code: Select all

result := (var1 Op(vOpName) var2)
Thats what I was refering too.
Since some of what I intend to do, would be inappropriate as GitHub PRs
What do you mean by that? that its impossible to express in C++ with the current AHK source as base?
If so then your request is not useful anyways (since it discusses something that cannot be done).
Recommends AHK Studio
User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 02:40

- I agree with what you said about operators. It was more pseudocode. This, that I mentioned, would be an alternative: var1 MyCustomOp1 var2. A finite (or infinite) number of redefinable binary operators. Or possibly operators that could only be defined on the script startup, tied to an existing function.

- My intention for most threads would be: I would like to create a possible built-in function X, here is the C++ code for it, do you have any suggestions.
- I wouldn't do it as a GitHub PR, because it wouldn't be my immediate intention to try and get it into AutoHotkey.
- And any source code requests that did not relate to functions might be a bit different. E.g. here is some before/after code for a specific part of the source code. Or more general queries about: where is this information stored, how could I implement this.

- Oh btw, I was looking for a way to list all of the functions defined in a cpp file. I am currently retrieving the text from a treeview in Notepad++. But I think that it misses some of the functions. (Also a list of all the functions used in a cpp file would be useful, I've been parsing them using RegExReplace.) It has been very hard trying to find relevant information on Google.
Last edited by jeeswg on 15 Aug 2018, 02:57, edited 1 time in total.
User avatar
nnnik
Posts: 3469
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 02:56

I wouldn't do it as a GitHub PR, because it wouldn't be my immediate intention to try and get it into AutoHotkey.
If you want something inside Autohotkey you suggest it. If you dont want it you don't suggest it.

I think your approach of actively 'trying to make AutoHotkey better' might be getting in your way here.
There might be an objectively better path at single occasions, but most of the progress is done by encountering problems and finding new features to solve this problem more easily.
That can only be done if you do active development with AHK. Just find a nice topic and try to explore it with AHK and take note of common problems you find.

If you really do feel like your own suggestions are not nice enough to go through you could find suggestions of other people and defend them as PRs.
Recommends AHK Studio
User avatar
jeeswg
Posts: 5285
Joined: 19 Dec 2016, 01:58
Location: UK

Re: NumOp/StrOp (with respect to !=/!==)

15 Aug 2018, 03:13

- (I edited my post above re. listing functions.)

- Part of what I want to do, is to in effect have a set of threads that act as a tutorial, so that people are producing a higher quality of source code. And capable programmers can learn the ropes, and be, within a short space of time, ready to add to/amend the AHK source code. Or even look for/spot bugs.
- Also, sometimes it's good to share source code with other people, and test it for a while, before submitting it as a PR. Testing leads to new ideas, tweaks.
- Or maybe I want to establish certain key things (learn about how to do something, a small part of the code), but produce the final source code a month later.
- It does seem odd to me that there isn't currently a place to just discuss aspects of the source code, other than submitting a major change to it.
- I suppose that you and Helgef are just teaching yourselves, but I would bet a bit of discussion now and again would expedite things, get you where you want to be faster, and strengthen your skill base. (I think that the challenge in editing the source code, is more about knowing the source code, than knowing C++.)

- I'm not sure what you mean by 'trying to make AutoHotkey better'.

- I don't think that people should submit PRs unless they really think it's got a chance. Otherwise they're wasting their own time and lexikos's time. I've seen a lot of half-baked ideas on the PRs, even though there were good aspects. They would have been better as AHK forum threads, that people could refer to and develop, possibly years later.
- I doubt people's ability to properly gauge what a good PR is, and I do not think going 'bang, here's a PR, make a decision now on whether it should be implemented or not', is a good idea, I'd rather it be visible during the creation process, and lexikos could even chip in and make a suggestion if he wanted to.
- I don't think you, me or Helgef are especially adept at knowing what lexikos would approve of in advance. If it's important to him, he's probably already implemented it, or mentioned it. But then again Max/Min and !=/!== were accepted, so what I do know. Also, I think making the argument is an important part when convincing lexikos, so if the thread has been there for a while as a function is being created, it gives him time to consider and potentially approve the idea before it's finished. Even if a function/idea is good, we shouldn't bloat AHK.
- Also, I think we could do with some more coordination. You, me, Helgef and others could make a wish list of things we would like (I already have), and if lexikos says I like that or an aspect of it, it would be motivation to get on with creating it. Instead of spending an age on something that was just going to get rejected anyway. So, that way people use their time more productively.
- Ultimately you can also be working on code that you might use in a non-AutoHotkey capacity, so if it wasn't used in the AutoHotkey source code, that wouldn't have been time wasted.

- Btw I should mention that by instinct I'm fundamentally against the PR idea for new ideas, although amendments (bug fixes) might be a different matter. If someone wants to suggest something new, I'd want them to post the finished code to me, or a complete section of specific code (and I'd do the rest), and I'd finish the thing off in my own style.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 8 guests