Alan Kay's restrictive definition of OOP is a lot easier to apply than the buzzword-list definitions. It clearly rules out a lot of languages.
C++ 'OOP', by comparison, is little more than syntax sugar for calling functions that take a struct pointer as their first parameter; a feature to make the compiler forcefully limit the access scope of certain members; and a v-table implementation.
I really like Go's OOP implementation because it doesn't pretend to be anything more than the 3 features listed above.
> This isolation is really enforced at the heap level
This is a very good point. True messaging OOP with "extreme late-binding" requires by definition that no object knows the memory layout of any other object. In practice, we achieve this by putting everything on a heap.
That characteristic is against C++'s goals. Heap isolation is useful for implementing certain features but it is not acceptable to apply it to the entire program when runtime performance is important.
But if you don't require the pattern everywhere, it really cuts down on the reusability argument for OOP, because inevitably you will want to change a part of your program that doesn't use the heap isolation.
It's also hard to reconcile Kay's definition of OOP with C++'s strict ownership semantics. It seems like Kay's OOP requires a garbage collector almost by definition.
C++'s template system is almost like the dual of Kay's OOP.
Instead of messaging, every function call is a candidate for inlining. State might be hidden by the `private` keyword, but all memory is accessed directly. All things are bound at compile time.
C++ 'OOP', by comparison, is little more than syntax sugar for calling functions that take a struct pointer as their first parameter; a feature to make the compiler forcefully limit the access scope of certain members; and a v-table implementation.
I really like Go's OOP implementation because it doesn't pretend to be anything more than the 3 features listed above.
> This isolation is really enforced at the heap level
This is a very good point. True messaging OOP with "extreme late-binding" requires by definition that no object knows the memory layout of any other object. In practice, we achieve this by putting everything on a heap.
That characteristic is against C++'s goals. Heap isolation is useful for implementing certain features but it is not acceptable to apply it to the entire program when runtime performance is important.
But if you don't require the pattern everywhere, it really cuts down on the reusability argument for OOP, because inevitably you will want to change a part of your program that doesn't use the heap isolation.
It's also hard to reconcile Kay's definition of OOP with C++'s strict ownership semantics. It seems like Kay's OOP requires a garbage collector almost by definition.
C++'s template system is almost like the dual of Kay's OOP. Instead of messaging, every function call is a candidate for inlining. State might be hidden by the `private` keyword, but all memory is accessed directly. All things are bound at compile time.