Binding data and functions together beats operating on global data visible to everything. One of the big wins of OOP is less exposed global data.
A big problem with OOP in C++ was that it wasn't opaque enough. The headers needed to use an object contain info only useful to the object's private functions. This creates recompile hell.
Multiple inheritance is seldom worth the headaches.
Overriding a member function needs declaration support. The usual cases are 1) the parent function needs to be called first, 2) the parent function needs to be called last, and 3) the parent function needs to not be called at all. Which case is to be used is properly a property of the parent, but in most OOP languages, it's expressed as code in the child.
The use cases for generics are rather limited. Collections, yes. Beyond that, it's usually someone getting cute. That way leads to the "metaprogramming" mess. Go has a few built in parameterized types - maps, arrays, and channels. Go2 may have generics, but the designers are struggling with what to add that doesn't take them down the rabbit hole.
Objects are probably more useful than some of the things invented to replace objects, like "traits".
That's a good idea! Although... I wonder if you would get tired of passing around the same piece of data between such functions all the time? Here's a crazy idea: what if we pass the data implicitly to such functions? Like, we could pretend that the data was passed to the function as a hidden argument, and we could call this argument "self" or "this"! :O
Or! You could just pass in a data structure without methods! The problem with global variables is implicit dependencies, and with “this” or “self” you now have slightly scoped implicit dependencies. I say slightly because you still have to worry about base classes. It’s the same problem just more contained.
> Binding data and functions together beats operating on global data visible to everything. One of the big wins of OOP is less exposed global data.
“Passing state as parameters” is what solved the “everything operating on global state” problem. Binding functions and state permitted polymorphism/abstraction.
> Multiple inheritance is seldom worth the headaches.
Single inheritance is never worth the headaches. :)
> Objects are probably more useful than some of the things invented to replace objects, like "traits".
Traits don’t replace objects; they are interfaces with static dispatch semantics.
There are so many kind of polymorphism. Many of them do not require objects. Executing a closure is a form of polymorphism. As is manipulating a generic type.
Binding data and functions together beats operating on global data visible to everything. One of the big wins of OOP is less exposed global data.
A big problem with OOP in C++ was that it wasn't opaque enough. The headers needed to use an object contain info only useful to the object's private functions. This creates recompile hell.
Multiple inheritance is seldom worth the headaches.
Overriding a member function needs declaration support. The usual cases are 1) the parent function needs to be called first, 2) the parent function needs to be called last, and 3) the parent function needs to not be called at all. Which case is to be used is properly a property of the parent, but in most OOP languages, it's expressed as code in the child.
The use cases for generics are rather limited. Collections, yes. Beyond that, it's usually someone getting cute. That way leads to the "metaprogramming" mess. Go has a few built in parameterized types - maps, arrays, and channels. Go2 may have generics, but the designers are struggling with what to add that doesn't take them down the rabbit hole.
Objects are probably more useful than some of the things invented to replace objects, like "traits".