5 hours ago, Kaetemi said:
In game development, code is indeed generally about transforming one chunk of data into another chunk of data, yeah. The use of OO does not bring that much to the table for that purpose. I think a lot of the OO push comes from the enterprise sector. From that POV, programming is largely concerned with storing and retrieving records of data, where real world associations do make sense.
In my view, OO is about "smart data", data that you can ask questions. "please list, tell me how long you are", "please monthly payment page, give me a summary of your information". Small functions you can "hide", attached to some data. I think this makes perfect sense.
The next step is to write some functionality that eg all instances in an inheritance tree share, say, an equality member function. This recurses down the composition tree, until you hit the basic case, and then it recurses back up giving you the result. For me, a more common functionality is to transform an instance to some other form, eg convert an expression instance tree to text.
If you write that the OO way in a class hierarchy with 20 classes (expression classes tend to get a lot of distinct cases), it works, but your single transformation function gets scattered across those 20 classes. Writing it is quite doable, bug hunting is a lot less doable, since to read what the code is doing you need to have 20 tabs in your editor or 20 printouts of a method of 5-10 lines. So instead, I write a single function "transformToText(expr)" (or an "equals(obj1, obj2)" function). That function is a long list of "instanceof" tests, one for each class, and for each case, I write the 5-10 lines of functionality for that class. I find that works much better, even though it totally is against OO methodology. I don't buy the Java/C# gospel (everything is an object), nor do I buy the C gospel (everything is a function), I mix them to write code that is as readable and maintainable as possible.
In my view, OO methodology should say more often when it should not be applied, instead of saying "everything is an object" and then failing its own gospel by having static methods. That would make it more clear which part of coding is still unsolved.
6 hours ago, Kaetemi said:
However, at which point should a function be a method in a class, and when should it not? Does it actually even make sense to specifically declare class methods? I'd find it more convenient and style-flexible if these ways of calling a function were just syntactic sugar for the same function.
Python does this, "a.f()" is truly equal to "f(a)", with the technicality that "f" may be findable only by writing "MyClass.f" in the second case. This is why it has "self" as standard argument in all methods of a class.
6 hours ago, Kaetemi said:
You could even go as far as making "properties" just syntactic sugar for a function call. A getter is a function that returns something, a setter is just a function that takes some parameters (and yes, why not have properties that take and return tuple values).
Python has a standard @property decorator for this.
Personally, I avoid getters and setters if they don't do anything, I just give public access to the variable instead, with the implied restriction that "looking in data is fine, changing it only if its owner agrees". The underlying idea is that all objects aim for the same goal, and thus cooperate with each other for that goal. No need to protect yourself from your friends.
3 hours ago, Oberon_Command said:
I agree on equality, that should be automatically generated and I've never been clear on why it isn't
I like "bool operator==(const A &a1, const A &a2)" a lot more than "a1.equals(a2)". Equality for me isn't instance specific so the latter doesn't make sense at all to me. It could be class specific, but really it's weird if you have more than one equality notion on a class in a single program (as such, specifying that with each use of a sort algorithm may no be the most useful solution).
One of the problems in code is perhaps that we use identity as equality notion a lot, that is, mathematical equality is relatively rare. Perhaps a language should be created that by default has no equality at all.
The difference between equality and order is that the latter requires a specification which fields to compare first (and how, ascending or descending). For this reason I see these cases as being different.