Prototype vs class-based OOP

Blog
1

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:

[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++.
I am mildly familiar with Javascript, but I dislike it deeply as a language. It so happens that JS uses prototype based inheritance, so I thought that was the end of it. I can’t understand prototype-based languages. Basta.

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 :tada:.:person_facepalming:.

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 :).

  • You really don’t need inheritance

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 Animal → Dog, Cat, Man example that we always get in school.
Confirmation bias much?

  • Explains how prototype inheritance is supposed to work

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 :smirk:.