While working on
Tippy2 (will be renamed after development back to
Tippy) here, I got very, very confused on AHK’s Class system, more specifically how and why static and local class members are accessed.
Here are my 2 discussions on the topic:
- Discord: Help with class static property access from inside class
- AHK forums: Help with class static property access from inside class
[TODO: more words here about the issues with AHK and statics, locals, and classes]
I initially thought
geekdude nailed it:
The problem, I think, is that your baseline for what a “normal” programming language should be is more narrow than AHK
Which is true: I am familiar with languages which use class based inheritance: Java, Kotlin, C#, Python, C++.
It turns out it’s not as black and white (it never is, is it?). AHK’s ~implementation~ choices for statics are kinda weird, and in the transition from AHK v1 to AHK v2, they were changed even more ..
Reading on the subject, I started reading a bit more on why does prototype inheritance exists, what are the differences and pros or cons.
Here’s a list of links I found interesting on the subject. While reading this, take into account that Kotlin > Java :).
This is a philosophy i already agreed with. Composition is just that much more flexible. I like this article in particular because it shows a good counter-example on the
Man example that we always get in school.
Confirmation bias much?
I like the explanation of prototypes along with the examples.
The author uses Java as a comparison language and while I don’t agree with all his conclusions and examples, I think I can understand his stance. One of my biggest disagreements is regarding the modification of properties (add/delete properties) dynamically at runtime. I would say having types statically defined and checked by the compiler is especially valuable in large medium to projects. Why would I want something to explode in my face at runtime because of typo?
In my opinion, that dynamicity is a disadvantage.
Instead of thinking of objects inheriting from other objects they think of constructors inheriting from other constructors and then become utterly confused.
Also explains that JS prototype inheritance is badly designed .