Two things preventing AutoHotkey v2 from moving forward

[iseahound]

I've given a lot of thought to how AutoHotkey should be used, but two things seem to be missing compared to other programming languages.

String Representation of an object
That is to say, the ability to covert an object with functions into data. It doesn't have to be a string, even extending the JSON-like syntax would be fine. The reason I think this addition is required is because although AutoHotkey prides itself on being a prototype based language, prototypes are actually inferior to class based objects in actual AutoHotkey usage. The main offender is functions. The prototype representation has to use obj.fn := Func("Some_Function") which forces Some_Function() to be declared globally. This is inferior to the class-based model where functions have a local scope, inside of a larger super-class.

True Instantiation of Objects
This means that when I call new on an object I get a real copy of the object - not a copy of its data and links to its methods. For example if a class' method has a static variable inside of it, and I create 3 copies of that class, updating the static variable in one class will affect the static variables in other classes. This completely defeats the whole point of instantiating an object - I need a new copy. (I understand there are workarounds in v1, however this needs to be resolved for AHK to move forward. I don't mind the limitations.) In Functional Programming, the use of the .clone() method on data is equal to the use of the new operator in Object Oriented Programming. The only difference I can see is that there is room for manual implementation. In the same way that the __Delete() meta function overrides the automated garbage collection, the __New() meta function overrides handling of Clone(). Both new and clone are so similar, they should be related somehow.

Finally, binding arguments to functions shouldn't be as difficult as it is. Calling a bound func like %boundfunc%() is really weird and annoying. I understand some functions that are variadic prevent function binding from being more intuitive. For example, a greater than 100 bound func can accept multiple parameters. greaterThan100 := Func("Max").Bind(100) But there has to be a better way than %greaterThan100%().

[guest3456]

no idea about your suggestions, they may be good or not

but certainly these are not the things that are preventing ahkV2 from moving forward.

[nnnik]

Your suggestion for the new operator is nonsense and trash.

[swagfag]

i agree with 3, there has to be a better way

[nnnik]

Sorry I might have been to blunt here. I apologize.
In my defense I write the comment while being half asleep.

[iseahound]

No worries. #1 probably relates to some deep mathematical theorm, the idea that you can "flatten" an object and later resuscitate it. I think pickle in Python does the same thing, not too sure.

#2 is basically the streamlining of all "copy" operations. You could say that all elimination rules follow from introduction rules. If AHK decides to create a linked copy - copies that contain references to methods, not actual copies of methods, the introduction/elimination rules for such a copy should be different from a full copy. Fixing the deep/shallow linked/not linked issue would support both OOP and FP. Object oriented programming is nothing more than a delegation to a base object. Likewise FP is nothing more than delegation to past copies of data. However where as OOP favors the depth of an object (isolating and containing separate features) FP favors the width of an object (moving data to the surface to make it easier to access) so far, clone only creates a shallow copy and new creates a copy with references...

I suppose you could make the argument that circular references prevent a deep copy from being made, but solving #1 (object -> string) makes #2 trivial

[iseahound]

This would bring AHK more in line with mathematical ideas, and become a lot more similar to Python. We'd also get one of the best features of any programming language: pprint or pretty printing - allowing us to look inside objects (object -> string -> IO, either MsgBox or stdout.)

[nnnik]

#1 is easily doable I guess - if we could settle on one standard - but I generally agree we need something for people that get into objects and want to see their content.
(And canot write their own object serialization functions yet)
#3 is something I would welcome with open arms but I dont feel as strong about as many others. I think it's fine the way it is.
But if someone does find a way I'd be happy to see it added to the language.

With #2 I see a few problems.
I'll disregard the fact that we have to completely relearn the styles, redesign many established patterns and rewrite many scripts using objects for now.
I'll also leave the discussion on whether this is an advantage or not for now.
I see a few features that are challenged by this change and will establish how and why they are challenged and which solutions I see.
You can then easily tell me if I misunderstood your suggestion.

Meta Methods like __Call, __Get and __Set are triggered once AHK does not find the key inside the initial object and goes down to the next base object.
If I understand your suggestion correctly the base object would fall away and the original object now contains __Call, __Get and __Set. Just like all the keys inside the base object.
This would complicate things because the current behavior has to change - the options I see are:

• Remove __Get, __Set and __Call
• Change __Get, __Set and __Call to work on the local object
• Add a new setting to objects that allows us to handle __Get, __Set and __Call in a seperate way
• You mention something with linked copies maybe there is something there I do not see.

I wouldn't want to remove __Get, __Set and __Call.

When we change __Get, __Set and __Call to act immediately when a key is gotten from an object we might encounter new problems.
If people assign any values to the keys __Get and __Set, getting or setting a value in the object might call some code unintentionally.
This is a massive risk for security and bugs. Handling it like this seems problematic.

Code: Select all

arr:= {__get:"shutdown"}
Msgbox arr[1] ;would trigger the execution of the function named "shutdown"

At the very least we would have to have a seperate Associative Array object type that does not have __Get, __Set or __Call behavior.

Another way of handling this would be adding a "metaHandler" setting to every object.
It would be accessible by methods using a method similar to the current base but will only handle __New, __Get, __Set, __Call, __Init, __Delete and potentially _NewEnum.
The difference to the current base design is the fact that the metaHandler itself cannot have another metaHandler - where as a base could have another base etc...
This would solve the problem with your design and meta methods overlapping with object keys.


Another problem I see is with COMObjects and internal AHK objects.
Currently you cannot make copies of internal AHK objects and COMObjects and your new new operator would fail for them.
We could fix the internal objects wth a lot of efforts, but Im not convinced it will be perfect.
For COMObjects there is nothing we can do - they would be completely seperated from the object hierachie.

In the current design however an Internal or COM Object could be the base of a normal object.
Any calls, properties, values etc that are handled by the normal object will be handled by it.
Anything thats not handled by it will end up with the normal object that we extend.
Working example:

Code: Select all

file := new fileExtender(fileOpen(A_ScriptFullPath, "r"))
file.extendedFeatures()

class fileExtender {
	
	__New(fileObject) {
		thisFileExtenderBase := fileExtender.clone()
		ObjSetBase(thisFileExtenderBase, fileObject)
		ObjSetBase(this, thisFileExtenderBase)
	}
	
	extendedFeatures() {
		Msgbox These are the extended features of the file extender - pretty useless atm
		Msgbox % this.read()
	}
	
}

I do not see how we could fit this into the new object architecture.

[SOTE]

I've given a lot of thought to how AutoHotkey should be used, but two things seem to be missing compared to other programming languages.

no idea about your suggestions, they may be good or not

but certainly these are not the things that are preventing ahkV2 from moving forward.

I think that AHK v2 has much more fundamental issues facing it that need to be sorted out. Some of these deal with:

1. Being newbie and non-programmer friendly enough. Targeting the general user, or already experienced or formally trained programmers?
2. Ease of use versus AHK v1. Is it easier or more difficult to write code in?
3. Choices of syntax, where AHK v1 looks simpler to use and understand than AHK v2
4. Massive amounts of user contributed scripts being in AHK v1, so easier to learn from or use those examples
5. Necessity and compelling reasons to switch from AHK v1. Why switch to AHK v2, when you are comfortable with AHK v1?
6. The pain it will cause to switch and rewrite scripts from AHK v1 to AHK v2
7. The likelihood that you can convert AHK v2 features and functions back down to AHK v1
8. AHK v2 being incomplete and still Alpha

I also question the thinking of trying to make AutoHotkey like other programming languages, versus the niche it is in and being better at it. Some of the choices of other programming languages, like in regards to how they implemented OOP, were arguably very bad ones. Debatably, AutoHotkey should be more cautious or more concerned about it's main target audience, particularly in regards to automation (like web browsers and non-standard GUIs) and as a more handy and useful utility program creator.

[iseahound]

Well that's the entire point. AutoHotkey is about automation, and automation deals with effect management. For one thing, in Computer Science we talk about functions, but we don't mean that we only want the return value of the function, we want the side effects of the function. Simple things like pow(n, e) which raise a number to a power can be called a function. Most of what we do here at AutoHotkey are processes, like setting values in the registry, or drawing something on the screen, sending key strokes, etc.

You'll find many other Robotics Process Automation (RPA) software on the market, and one thing they seem to love is the try, catch loop. The try, catch loop, along with sequential actions are designed to Automate other programs, and "recover" if something goes wrong.

That's a crude approach to the problem of having two programs, and having one program being the "smaller" program (AHK), automate the larger one. Having a list of sequential actions to do does not suffice, the smaller program needs to keep track of the state of the larger program. Doing so would prevent the need to "recover" the program, or use try catch control flow.

So in the scenario where we have two programs, a smaller program keeping track of the state of the larger program, where actions taken by the smaller program affect the larger program, and actions taken by the larger program recorded by the smaller program, we get something called a bisimulation. We've departed mathematics, and entered philosophy. First is the obvious point, the smaller program can not completely simulate the larger program. If the smaller program does completely simulate the larger program, then it would be identical (pragmatic maxim?) to the larger program. The whole point of having a smaller program is to lower complexity, to "compress" information. So where does the extra complexity go? Some of the complexity is omitted altogether, so that the smaller program only interacts with a subset of the larger program. Some of it is ignored, and becomes entropy, because entropy is the measure of ignored information. And so we need to redefine how the smaller program keeps track of state. Some events are necessary, meaning the smaller program must have them occur for it to continue automating the larger one. Some events are possible, because software sucks and random pop ups and errors are a thing.

I could go on but the language needs to be more expressive.

@nnnik I like the base object and meta functions. In fact there should be more meta functions and operators associated with meta functions. new for __New(), obj := "" for __Delete, obj.fn() for __Call, etc.

[tank]

RPA

now this is my area. so i will get in on this

they seem to love is the try, catch loop

You lost me here. Not AA, Not Blue Prism, Not UIPath???? Maybe you mean something else

the smaller program can not completely simulate the larger program

HUH. I have written entire applications using AHK enhanced with automation. I have used ahk vanilla professionally for 8 years and 1.1 since. I have yet to find anything meaningful i couldn't do with it. I grant you syntactically its a train wreck. but have you seen some of the
quirks of ECMA 6
quirks of ECMA 6
C# Quirky as fu k
Nope I am a sea horse your arguments are invalid

7bffebfb8c81708b0923be9795d2867a.jpg (101.19 KiB) Viewed 3728 times

[guest3456]

seems like iseahound learned a new functional programming/math concept, and is trying to force it on AHK

[kczx3]

Actually, #1 is currently doable I think now that we have nested functions.