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.
Modifying Built-In AHK Objects (against?)
Re: Modifying Built-In AHK Objects (against?)
It is fine, but for shared code there could be conflicts. (My personal opinion)
Cheers.
Cheers.
Re: Modifying Built-In AHK Objects (against?)
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?
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: Modifying Built-In AHK Objects (against?)
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,
Cheers.
Code: Select all
; lib 1:
gui.prototype.x := t=>msgbox(1)
; lib 2:
gui.prototype.x := t=>msgbox(2)
; code:
gui().x()
Re: Modifying Built-In AHK Objects (against?)
@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.
Thanks for your reply. That certainly makes sense. I see the 2nd lib in your example overwrites the 1st lib, and with no warning.
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: Modifying Built-In AHK Objects (against?)
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.
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.
Re: Modifying Built-In AHK Objects (against?)
@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.
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.
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »