Modifying Built-In AHK Objects (against?)

Get help with using AutoHotkey (v2 or newer) and its commands and hotkeys
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Modifying Built-In AHK Objects (against?)

Post by TheArkive » 21 May 2022, 02:38

I'm just wondering about other people's reasons for being against modifying built-in AHK objects

I happened to go down the path of modifying built-in AHK objects due to ease-of-use, but I also was trying to understand the developing features of AHK v2 as it was being developed. My reasons were firstly, personal preference and convenience, and secondly, I was trying to implement extended GUI functionality in a native way.

So what are the personal, professional, and other reasons for not extending AHK's built-in objects? I only ask because I want to understand other perspectives.

Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Modifying Built-In AHK Objects (against?)

Post by Helgef » 21 May 2022, 07:45

It is fine, but for shared code there could be conflicts. (My personal opinion)

Cheers.

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Modifying Built-In AHK Objects (against?)

Post by TheArkive » 21 May 2022, 08:28

Helgef wrote:
21 May 2022, 07:45
It is fine, but for shared code there could be conflicts. (My personal opinion)
I have certainly thought about this. But how would these possible conflicts be any different from any other malformed code?

Is it mainly from the idea that AHK v2 is still in beta, and can still change?

Or is it more so that there may be some kind of unintended side effect by modifying the built in objects?

Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Modifying Built-In AHK Objects (against?)

Post by Helgef » 21 May 2022, 08:45

If you include two libs and there are conflicting functions/classes your code won't run. But if multiple libs manipulate the built-in objects you will get no warning if there are conflicts, eg,

Code: Select all

; lib 1:
gui.prototype.x := t=>msgbox(1)
; lib 2:
gui.prototype.x := t=>msgbox(2)
; code:
gui().x()
Cheers.

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Modifying Built-In AHK Objects (against?)

Post by TheArkive » 21 May 2022, 08:48

@Helgef

Thanks for your reply. That certainly makes sense. I see the 2nd lib in your example overwrites the 1st lib, and with no warning.

iseahound
Posts: 1434
Joined: 13 Aug 2016, 21:04
Contact:

Re: Modifying Built-In AHK Objects (against?)

Post by iseahound » 21 May 2022, 12:31

Modifying built-in objects is a matter of convenience. You could not do it, but it makes the code more verbose.

1) Standalone script / exe - Do whatever you want.
2) Library - Please don't. (unless the entire purpose of your library is to extend built-in classes)
3) A single function - Just make sure that your function is sandwiched between Critical On and Critical Off and replace any modifications you've made to the original state.

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Modifying Built-In AHK Objects (against?)

Post by TheArkive » 22 May 2022, 00:12

@iseahound

Thanks for posting. I'll certainly keep those in mind. I'll also put explicit warnings on my obj extension libs regarding the issue that Helgef mentioned above.

Post Reply

Return to “Ask for Help (v2)”