Reconsideration request? Topic is solved

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

Re: Reconsideration request?

11 Dec 2017, 10:14

- @derz00: Please explain what you mean. If I add a function or feature to a script, or someone does the same, but to AutoHotkey, that's development. Even if it's a minor change. Development consists of minor or major additions/changes to software.
- Right now, AutoHotkey does not need anything essentially *new* to become reputable. So in effect it doesn't really require 'development' to become reputable. Fundamentally it needs to repackage commands as functions, and that's it. When I introduce programmers to AutoHotkey, I do so with function versions of commands, there are enough things to get used to (in any programming language) without commands that each have individualistic syntax traits.
- Right now, I believe that getting good programmers in to write good AutoHotkey scripts, is more important than improving AutoHotkey v1/v2. By attracting say 5 to 10 more programmers gifted in COM for example, the forum would be comparable in quality to Stack Overflow. And I believe that that that should be done by editing the documentation to make it clear that some commands/functions are deprecated e.g. StringReplace v. StrReplace. And to make an official/semi-official 'commands as functions' library. This is what AutoHotkey needs to be 'reputable', in my opinion, and that's been obvious for at least a decade.
- I would propose that instead of waiting for AHK v2, to make AutoHotkey reputable, the AHK leadership might say, 'OK we believe that these functions are ready for AHK v1, let's have a month's consultation period, to delay releasing any controversial functions, then release them with the installer (as AHK or C++), they can still be changed in future, but we expect that the need is unlikely'.

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

@derz00: I don't know what you think I have or haven't addressed re. nnnik's points. Here are some specifics.

The issue with AHK v2 is that currently nobody is actively developing it besides lexikos.

We need to attract more people then (to AHK, some of whom will know C++), and any willing devs need to work out how/if they can be helpful to lexikos and offer their services.

What AutoHotkey lacks right now is developers not someone that will smooth the transition from AHK v1 to AHK v2.

I don't really understand this point. All we need is the AHK leadership to say here is an official/semi-official AHK lib of functions for AHK v1 commands. Almost nothing and almost nobody are needed to smooth the transition.

We don't need to attract developers that might help with the project in the far future.

We need to attract developers of AHK scripts now, and of C++ for the future. Those people are probably the same people.

We need someone that develops and we need this person now.

There have been times when AHK urgently needed new features. But not now. Obviously I welcome every AHK development, major or minor. I want 'reputable' AHK now (achievable with one ahk file lib, that I've been keeping up-to-date), and AHK v2 when it's ripe, and not expedited.

It is difficult for me to tell in which direction lexikos wants to take AHK.

Warum fragst du nicht lexikos?

[EDIT:] I have almost finished converting all my main scripts, it's slower than it would have been because I'm trying to create scripts for automating conversion as I go along, plus I was waiting for any AHK v2 updates. I'll have a great collection of notes, comments and scripts, perhaps within the next few weeks.

[EDIT:] Going through this post, it's quite clear why the move to functions wasn't faster/didn't really start until AHK v2 alpha. That's not really a criticism per se, but it has been quite unfortunate in terms of the growth and reputation of AHK. Nevertheless, the reputation has grown, and it will be fixed in the near future, it will be where it should be.
Commands as functions - Scripts and Functions - AutoHotkey Community
https://autohotkey.com/board/topic/3531-commands-as-functions/

Cheers.
User avatar
derz00
Posts: 404
Joined: 02 Feb 2016, 17:54
GitHub: derz00
Location: Middle of the round cube

Re: Reconsideration request?

11 Dec 2017, 11:09

(achievable with one ahk file lib, that I've been keeping up-to-date)

I don't really understand this point. All we need is the AHK leadership to say here is an official/semi-official AHK lib of functions for AHK v1 commands. Almost nothing and almost nobody are needed to smooth the transition.


I suggest you start another thread discussing the facts and practicality of the statement: "achievable" and allowing @nnnik to explain his point. I am left confused by a lot of your conflicting statements. e.g. "AHK doesn't need developed" then "waiting for any AHK v2 updates" ???
try it and see
...
coffee
Posts: 45
Joined: 01 Apr 2017, 07:55

Re: Reconsideration request?

11 Dec 2017, 11:11

jeeswg wrote:- @just me: I said 'the best of both worlds', stability is good, functions instead of commands is good. Clearly increased overhead is bad, however, if AHK v2 isn't fully optimised yet, perhaps there is overhead there also? (When AHK v2 is officially released, I'll be happy to encourage/help people to move over.)
- Also, just how much overhead is there, I'd like to know. You're welcome to furnish this thread with the results of some benchmark tests. Plus, there are advantages in writing code when you have functions available, to make certain things more fluid.

You can run the tests from the ahk performance thread, and come up with the conclusion that all the toxic gimmick syntax ahk v1 had to make it "faster", are not needed in v2 and only provide a marginal gain (sometimes are actually slower). Calling the leftover commands (g_act[]) as functions in v2 is a tad slower than not using the parenthesis, but overall, ahk v2 performs faster than v1. But I would like to put that between quotes since it's not like we are folding at home with autohotkey.

One way to promote moving people to v2, is for the "autohotkey foundation" to actually do it and for everyone to stop treating v2 like it's some sort of completely unstable code that will bsod your computer if you try to do anything. Unless lexikos starts porting back changes from v2 to v1, current v2 syntax will probably be more compatible in every way to future v2 releases than the current v1 syntax.

There are also some changes that can be done in v2 while it's being "finished" to make the transition easier by keeping things separate that do not take long at all, or that much code for that matter. Like adding %a_ahkpath% or %a_desktop% to #include, adding a lookup for a folder called "Lib v2" in a_mydocuments\autohotkey, before "Lib" is used for pulling functions, so you could start "transitioning your libraries to v2" without affecting v1.

Lexikos didn't remove the code for variable derefences in strings, you can add #define ENABLE_TEXT_DEREFS 1 to the defines.h and you get variable derefencing back. The code is still there. I think the reason he added the directive is because he didn't want people using "%var%" because he could change his mind later and make it "%{var}" or whatever else, then get unwarranted shit for it.

You can also use something like autohashbang, adapted to your own needs, to create a preparser that will dynamically choose the exe version to run either with a path or an alias. So you can run v1 scripts and v2 scripts in the same system without having to bother using a new file extension. Mine only adds between 0.8-5 milliseconds on script launch and that is including pulling alias from an ini file and using an autohotkey autofind function in specific paths relative to the script, which is negligible unless you are going to be launching 1000 scripts per second, and it only affects "launching" the script, everything else stays normal once it's handed off to the chosen autohotkey.exe

Ultimately it comes down to what you want to do, some of the basic QOL that have been requested can be done easily. But if your intention is for you to share all your library to the world and porting-all-the-libraries you come across from other people into v2, then you are gonna have to wait for lexikos to finish up. But if you want things "for you" you can do your own "additions". Nobody can stop you, Autohotkey is GPLv2.

A lot of the other requests can be fixed doing what HotkeyIt is doing with autohotkey_h, using a bundled standard library of functions (shipped with autohotkey) to either expand his own internal changes or simply do it on pure ahk. Not everything needs to be implemented in source and not all of the implementation needs to be in source.
User avatar
jeeswg
Posts: 3595
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

11 Dec 2017, 12:19

- @derz00: In my AHK script-writing, I prioritised general scripts over conversion scripts, because the nature of AHK v2 is/was uncertain. This is a better way of saying 'waiting for any AHK v2 updates'. Thus, my conversion scripts will end being released later than otherwise.
- When was the word 'achievable' used?
- What is this magical point that nnnik made?

- To be frank, only for the sake of clarity, my line of thinking was this. If for whatever reason lexikos's 'Lost Weekend' grew into further months, perhaps he could tweak my 'AHK v2 functions for AHK v1' script, and so at least we could get on with 'pseudo-AHK v2', until real AHK v2 came out at some future point. The conversion surge could thus commerce, and AutoHotkey would finally gain the reputation it deserved. If you simply use functions instead of commands in AHK v1, I can't see anything to complain about syntax-wise.
- Re. writing the AHK source. People have their own ways of doing things, but in my imagination, using AHK custom functions to test out and perfect future AHK v2 functions in AHK v1, would be easier than experimenting with them in C++. Also, writing these functions in AHK first would facilitate quicker releases and response to feedback. Plus, users who know AHK but not C++ could experiment with the prototypes and maybe come up with some interesting ideas.
- This would also help to make issues like InputEnd and RandomSeed come to light, and would give you a ready made backport of AHK v2 in AHK v1. And so you'd only have to write the C++ code once, after everything had been ironed out in AHK. But again, people have their own ways of doing things, maybe there are other/better approaches.
- By getting this out of the way, you could then focus on all the interesting new stuff, whatever that may be, and do it direct to C++.

- @coffee: I really enjoyed your post.
- Obviously I like good performance, but these functions are only supposed to be used during the transition, and for making it easier to use future scripts in old versions where necessary or preferable. I.e. I don't mind if the performance is a bit worse, but would be interested to know how much worse.
- I don't want the Foundation to promote AHK v2 too soon, 'unconverting', as changes are made, is annoying for people. However, if we had a stated core of functions deemed pretty-much finished, we could promote a growing library of pretty-much finished functions, as they were finalised. With the proviso that edits could still occur.
- I've thought a lot about dereferencing, I do really like this: Deref("text%var%text"), I find % very clear, and I don't need or want anything else. Although the option to change the Deref character would be good for certain circumstances. Keep it simple! In my StrContains function I use comma as the delimiter, but allow a custom delimiter.
- I understand the worry about confusion re. %% deref and double deref, but users will be confused whatever you do, anyhow, users will or ought to know about environment variables in paths. %% double deref in variable and functions names, and %% in strings with the Deref function, that's the way to go, there are excellent parts of AutoHotkey, giving you much needed flexibility and simplicity. There are alternatives to %% in function names, however, I'd definitely keep %% in function names, and not only because it's more newbie-friendly.
- [EDIT:] Sometimes removing something makes things simpler: i.e. commands, and two types of parameter syntax. Sometimes keeping something is the way to go, %% double deref in function names and variable names, %% deref within strings used within the Deref function.
- I would like some kind of /inc switch, I would use that to handle AHK v1/AHK v2, via a go-between script that handles all AHK scripts (when you double-click them). I don't see the need for separate extensions, however some agreed convention to have some string to search for, in AHK files that indicated the version could be a good idea. Otherwise I would use scripts with A_AhkPath or A_ArgsXXX or A_AhkPathNoExt (this variable doesn't exist), if they were supported by #Include.
- Nothing I ever suggest is 'about me', everything is about generality. When I need something, I write my custom functions, or otherwise I adapt to AHK. Sometimes I seek live binary edits to the address space, but ultimately if you need to do this, you need a feature request. I only propose things that I think are fundamental enough to be parts of AHK, that have natural names and parameter orders, and won't need updating.
- People want functions to be compatible with #Warn, I don't need this personally, realistically I think 'assume local' is needed in order to achieve this. It's an awkward one, it's tonnes of work for me to support something I don't even particularly agree with, for the sake of the wider community and having one standard. I then have to ask for a feature request as a result, and I don't like asking for feature requests.
- My wish list ideas fall into two camps, and I will make a general thread re. the future of AHK, where I separate syntax ideas and anything that I can write myself as a custom function. Syntax requests are great ideas that should probably be implemented in both AHK v1 and AHK v2. With anything that can be made as a custom function, there is more leeway, we can wait longer, and have them in AHK v2 only, and the ahk script backport will have already been written in AHK v1.
User avatar
derz00
Posts: 404
Joined: 02 Feb 2016, 17:54
GitHub: derz00
Location: Middle of the round cube

Re: Reconsideration request?

11 Dec 2017, 12:32

jeeswg wrote:- When was the word 'achievable' used?
It is the first word in the first quote in this post: https://autohotkey.com/boards/viewtopic ... 70#p187970. But it is the entire statement that I was focusing on
- What is this magical point that nnnik made?


The one you couldn't understand
try it and see
...
User avatar
jeeswg
Posts: 3595
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

11 Dec 2017, 12:44

- @derz00: Yes, I misread your post because there was no comma after 'achievable'. To make it really straightforward, if everybody used my 'AHK v2 functions for AHK v1', which I've been writing, but which anybody could have written, and Coco, polyethene and lexikos and others worked towards. And if the main devs could confirm that say 80% of the functions were finalised. Then we could get on with conversion and start actively promoting AutoHotkey. This became more pressing to me as (a) AHK v2 development appeared to stall for a while, (b) more and more good code is being written in AHK v1, that will be difficult to convert to AHK v2. [EDIT:] I also felt that such a move could reduce the pressure in the situation, to allow AHK v2 to develop at the proper pace, and calm people who were agitated by the stall in progress.
- While I don't mind people being a bit argumentative, I'm not sure that your posts are as self-explanatory as they claim to be. And in fact, perhaps no-one in the world has interpreted it, nnnik's post, the way that you did. You found a deeper meaning in it, that others failed to find, and that nnnik didn't intend. I reread nnnik's post, I tried to address virtually everything in it, in order to answer your question. You could quote it with some notes attached.
User avatar
derz00
Posts: 404
Joined: 02 Feb 2016, 17:54
GitHub: derz00
Location: Middle of the round cube

Re: Reconsideration request?

11 Dec 2017, 13:25

:D sorry for pulling you around like this.
Spoiler




I'll just say again, you might focus further discussion (in a separate thread?) on the point of (hold your breath!!!) whether or not the v1 functions to promote two-way compatibility are worth the effort and expense**. For example, does nnnik agree with that fact? Does anyone else?

[took out a line that I feel bad about afterwards]

**
try it and see
...
User avatar
jeeswg
Posts: 3595
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

11 Dec 2017, 13:57

- I don't tend to want to talk about things too much, I prefer doing things. It's mainly as light relief that I engage in a bit of meta discussion, but often to slip some important points in, and it's the only way to gauge the wider community opinion.
- Re. nnnik's views on development. I've said before that I welcome users to write an extensive wish list of things that they would like to see in AutoHotkey. Concrete things. Re. thinking about the future, I don't mind talking meta, but specifics lead to greater clarity.
- Re. why posts can be unclear. Sometimes it's difficult to be clear when talking about the state/future of AHK, because of politeness. Do I want to be this frank: 'AHK v2 seemed to be stalling, people were in a panic, I suggested my 'pseudo-AHK v2 in AHK v1' idea as a stopgap, requiring minimal time commitments from any main devs, but also giving them greater freedom'.
- Also, anything you say about how AHK should be, could sound presumptuous, when merely intended as the best solution that you can envisage.
- People will often misinterpret what other people say, so you end up criticising someone for something they didn't say. If that happens, you can restate your original point.
- You can still quote nnnik, and I'll comment on it.
- Re. are functions worth it. Making function versions of the AHK v1 commands 12 years ago, was worth it, and updating those functions was worth it, it's been easier to gradually convert my scripts than to try and do it one go. The question of how worthwhile it is only emerges when a function is particularly fiddly to recreate. However, it's a bit of fun, a bit like doing a crossword, also, it helps to clarify how automatic AHK v1 to AHK v2 conversion must be done. It's also very useful for AHK v2 to AHK v1 conversion. I'm finding now that I need to 'unconvert' a lot of my AHK v2 code to AHK v1 to share on the forum. This is another reason why I want to push on to AHK v2 functions in AHK v1 now, and not wait any longer. Versus 'unconverting' things regularly, writing in both AHK v1 and v2 regularly, and doubling up on hotstrings for script-writing.
- Re. two-way compatibility. I haven't really talked too much about two-way compatibility re. functions here (in this thread), I've mentioned about using functions re. ending developer reluctance to use AutoHotkey amongst programmers from other languages. I'm biased, in my head I can excuse escaping command parameters with '% ', but when I step back, it's clearly wrong.
- Anyway, fundamentally I would say that a library that can be used in both AHK v2 and in 'AHK v1+functions', that saves you a ***LOT*** of bother. lexikos did recreate StrGet and StrPut for AHK Basic. Recreating DateAdd/DateDiff was basically the solution to someone's problem the other day on the forum. It could have already been made available and in the documentation for AHK v1.
Last edited by jeeswg on 11 Dec 2017, 14:21, edited 1 time in total.
User avatar
derz00
Posts: 404
Joined: 02 Feb 2016, 17:54
GitHub: derz00
Location: Middle of the round cube

Re: Reconsideration request?

11 Dec 2017, 14:09

I am completely confused. I acknowledge your post. I say no more due to lack of qualification.
try it and see
...
User avatar
nnnik
Posts: 2510
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Reconsideration request?

11 Dec 2017, 14:20

I'll be frank here. If you really think that we do not lack developers, that develop AutoHotkey itself, you are either blind or stupid.
The following systems would be better with OOP due to the way their information is structured:
  1. Files & Folder Access
  2. Windows & Controls
  3. Registry
  4. GUI
Out of these only GUIs are currently available in OOP.
There are several issues with consistency of newer and older functionality, where everyone needs to add some extra lines to be compatible with the newer functionality ( e.g. isFunc, func-object and boundFunc-object ).
I'd like to be able to extend internal classes like the file object the func object or the other objects.
And this work so far only covers converting the languages features to a syntax that has been present since AHK_L. It's work that should have been done in AHK 1.1.

Additionally to this work that we carry over from AHK 1.1 we need to enhance the core language features:
Working with binary data and structs in AutoHotkey is plain hell.
#Include needs work - as you have said - either with modules or namespaces ( where, towards me, modules are the preferable option )
We need some sort of typing system ( And I'm not talking about a simple type() function here )
AutoHotkey lacks closures or lamda functions, there are other language features that are nice to have that AutoHotkey lacks, but I can't remember them all atm. ( inline documentation that allows to document features and functions in your code in a specific standardised way so that editors and IDEs could read it and show it to the user )
Most of the requests in the wish list forums are rejected due to "low priority", which basically means nothing but "We don't have enough developers to cover this".
AutoHotkey lacks many functions or features that are neccessary for newbies to make the language easier and there are many repetitive pieces of code you need to write due to the absence of built-in functionality for that

Additionally we need to think about the languages identity:
AutoHotkey is nice for Keyboard automation and automating local programs. However we have reached the age of the internet since quite a while.
What about automating web services ( e.g. REST APIs )? Do we want to move there or is it unneccessary to follow these new trends?
As it is now AHKv2 is not newbie friendly anymore - you need to learn about Expressions to do easy tasks and example code can get easily confusing - do we want to restore newbie friendlyness and if so how?
Lexikos said that the documentation should just become newbie friendly :lolno:
If we switch from newbie friendlyness to a more advanced developer audience, speed gains importance, features for better debugging and error checking and logging gain importance, multithreading gains importance...
And if we target a developer audience, a package manager ( something that manages your includes ) of some sort is indispensable.

Also there have been multiple projects that advance AHK. There have 3 project managers and you basically mentioned all the people that created functions for commands for AHK v1.
They all are pointless unless they are bundled with AutoHotkey - barely anyone will use them unless it enables them to overcome a specific hurdle for their specific project.
If I just ignore AHK v2 I will never need your library, therefore I will not use your library. When developing people try to solve problems - using someone else library in AHK v1 also creates problems, using AHK v2 also only creates problems and does not solve any problems towards the standard AHK v1 user.
A different example of a good library would be the _Struct library - since it solves problems.
Recommends AHK Studio
guest3456
Posts: 2165
Joined: 09 Oct 2013, 10:31

Re: Reconsideration request?

11 Dec 2017, 14:26

derz00 wrote:It is your posts that I couldn't understand.

numerous people have told him the same thing, multiple times.
he refuses to change

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

Re: Reconsideration request?

11 Dec 2017, 15:36

- @nnnik: Many thanks for such a thorough response.
- Btw if I say something isn't important *to me*, I'm not saying it's not important.
- Re. major changes. It was precisely for this sort of thing that I started this thread. But no-one contributed. I like to see people's wish lists.
The Future of AutoHotkey (AutoHotkey: major new features) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=17&t=30482
Some such threads of mine have flourished, some haven't.
- Re. OOP. I had done a few things with file loops and registry loops, and had considered that a class for looping would be the best way to handle everything.
- I have done an absolute tonne of stuff with GUIs and don't find that objects add anything. Instead of oCtl.Text(), you do GuiText(hCtl). In my view, there is simply no advantage to using objects for GUIs, but people are welcome to use objects if they want to.
- Furthermore GUI functions can be used in a simple way to handle any hWnd or hCtl, for internal or external programs. Generally speaking the hWnd acts just as effectively as the object 'oWin' would. And to other people, I would seriously think about this, as an example of where objects are not needed.
- I don't mind using repeated NumGet and NumPut with structs, I don't find that I need to use structs particularly often. Or rather, once you've written the function that needs the struct, you don't have to return to it.
- What I don't like with structs is looking up the information, and uncertainty, I've been trying to collect this information. It's this that wastes a lot of time. It's the same with DllCall.
- I'm not sure what you mean by inline documentation. Comments that aren't at the end of a line, that are within the code itself, in my opinion, clutter things.
- I view wish list items being rejected as: we don't really need it, the dev's time is valuable, we don't want to bloat AutoHotkey, be more convincing. I feel that, more or less, AutoHotkey has what it needs.
- While I might agree that some newbie things are missing, I don't know which you have in mind. I generally think that most things are there. Re. newbies, I'm mainly concerned about breaking the principle of least astonishment, e.g. #Include doesn't handle some common variables, Sort doesn't use stable sort by default. Also, I don't ever want to have to give another lecture about why MsgBox/InputBox don't let you specify a large font, it's one of the first things newbies see, plus there are the issues of monitor resolutions and visual impairment.
- AutoHotkey can handle REST APIs, right? It's just COM? I think that AutoHotkey's future concerns include: Windows versions, the Internet, COM, interacting with external programs, UI Automation.
- The best solution re. newbie friendliness is to, every so often, add more classic examples to documentation pages. In fact that's even true now, a good example is needed for every command/function.
- For debugging, I want more info and more scripts, regarding how parsing takes place. Specially, scripts to extract, functions/variables/hotkeys from a section of code. If anyone can point me to the relevant parts of the source code, I would appreciate that.
- I haven't felt the need for any special #Include management.
- I don't view the _Struct library as a good example of solving problems at all. It's an unnecessary #Include dependency, I fixed InjectAhkDll to remove that dependency. I would prefer a library that creates the NumGet/NumPut lines for you.
- An example re. _Struct is Excel and macros. You can have a custom Excel function via a macro, but then you need to have to handle all the permissions and whatnot, every time you open the file, and the file won't work if data, and the macro, ever get separated. A better solution can be to have a macro workbook that generates hardcoded information in cell, or, complicated 'if' lines, and then use that personally, or share that with people. The workbooks are then macro free.

- I would welcome functions to help with DllCall and structs, something like:
- DllCallEx("user32\MessageBoxW", "tttui(i)", hWnd, vText, vWinTitle, vType)
- Struct(RECT, "iiii", vX, vY, vR, vB)
- StructPut(vY, &RECT, "iiii", 2)
- vR := StructGet(&RECT, "iiii", 3)

- Some things that I don't understand that you've talked about:
- I don't use bound funcs very much.
- Modules/namespace with #Include. What's a module/namespace? We currently just have a one-parameter directive specifying a path which takes literal text and certain A_ variables.
- OOP. People often mean different things when they talk about this. To what extent are AHK arrays 'object-oriented programming'? To what extent are AHK object classes 'classes'?
- Typing. People often mean different things when they talk about this.
- Closure.
- Lambda functions.
- Package manager.

- @guest3456: You, as is derz00, are welcome to your opinions. But, you're not stating your opinion, you enjoy playing the provocateur. One of the few things that people have praised me for, in the past, is that I give good explanations, and then, they can't understand why other people gave such bad explanations.
User avatar
nnnik
Posts: 2510
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Reconsideration request?

11 Dec 2017, 16:30

nnnik wrote:I'll be frank here. If you really think that we do not lack developers, that develop AutoHotkey itself, you are either blind or stupid.

I take that back. You just lack experience in the field.

jeeswg wrote:- I don't use bound funcs very much.
It's mostly important in the field of objects. -If you want to do a callback to a specific method of a specific method you will use boundfunc.
I always used isFunc to check if something is a callback. As I found out not too recently isFunc returns 0 for boundfuncs - meaning I have to change my way of checking for callbacks

- Modules/namespace with #Include. What's a module/namespace? We currently just have a one-parameter directive specifying a path which takes literal text and certain A_ variables.
- OOP. People often mean different things when they talk about this. To what extent are AHK arrays 'object-oriented programming'? To what extent are AHK object classes 'classes'?
- Typing. People often mean different things when they talk about this.
- Closure.
- Lambda functions.
- Package manager.
I'll make a larger post about this tommorrow in the tutorial section
Recommends AHK Studio
User avatar
jeeswg
Posts: 3595
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Reconsideration request?

12 Dec 2017, 15:47

- @nnnik: I look forward to any information/tutorials re. these functions. I've read a bit about lambda functions, any key example of how they would be useful would be great. To my mind it sort of (note: sort of) touches on ideas of dynamic code, a workaround being to write/launch a script and pipe out the output.

MINIMALISM
- I generally feel that AutoHotkey doesn't lack any functionality. I wanted Unicode and I got that. Though not ideal, I wonder if AutoHotkey could have used functions and binary data in variables to create a more or less acceptable 'pseudo-object', which would have been more satisfactory than using pseudo-variables. Although, crucially, this wouldn't have worked for COM.
- I wouldn't have known it at the time, but DllCall, RegEx and objects were essential features. And x64 support (which we have) would have been very important for interacting with x64 applications. I had no idea about COM or that you'd be able to automate Excel via AutoHotkey.
- Going over these things, questions of fundamental functionality, I'm reminded of the benefits of minimalism. For certain things AutoHotkey pushes you in a slightly restrictive direction, but this can actually be a good thing, one example is DllCall. In C++, Winapi and custom functions look the same. With AutoHotkey you know it's a Winapi function because you use DllCall and specify a dll. Slightly more verbose, but greater clarity, and better for debugging. When going over the AHK source code, it's useful to add a prefix to Winapi functions to identify them (so that you can look them up cf. trying to find them in the source code).
- My ideas for DllCall and structs are examples of where you start off at one place, and you try to improve things just a little bit, with the smallest tweak possible.
- DllCall uses half of the parameters to specify types, I think it would be better to use one, inspired by HotKeyIt's list of dll functions. See my DllCallEx idea in a previous post.
WinApi
https://hotkeyit.github.io/v2/docs/commands/WinApi.htm
- Similarly I like what HotKeyIt did with structs. So either, say, 3 handy functions for operating on binary data, or everything wrapped in an object. I'd want to succinctly hardcode any struct definitions, and not rely on a library of common structs. Like I mentioned before, re. Excel and macros, I like to reduce dependencies. I like to copy hardcode from a list, and not store reams of data in a separate library.
- Anyhow, I think AutoHotkey could improve generic support for DllCall and structs slightly, although I have not found this to be urgent. Anyhow, I haven't finalised the struct ideas yet, we'd need a notation system that could handle all the struct parameter types, which are more numerous than those needed for DllCall.
- I often find that if you need some kind of new coding structure/concept, you reinvent an existing idea. I.e. anything you really need, you tend to invent the idea yourself, if you hadn't already heard of such a thing elsewhere.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 1 guest