2 ms·
I think you have it backward: > But I think the tendency to "lock" behavior into functions and not letting objects define their own behavior is a major shortco
by mrkeen 3y ago
I think you have it backward:
> But I think the tendency to "lock" behavior into functions and not letting objects define their own behavior is a major shortcoming.
"Locking behaviour" happens when you bundle objects & functions together.
For instance, an OOP programmer might create a binary tree, mark the fields as private, and expose a public visit() method.
If you take away the "objects defining their own behaviour", then you're left with just the binary tree. Then different callers can write their own visit() functions.
- trashburger 3y agoVisibility as a concept is one I also disagree with :) I lump it together with the "OOP" classification in my original comment. I agree with you in this regard. The messages an object is able to respond to should not be restricted because of where it comes from.
- magicalhippo 3y agoI feel visibility should be there, but it should also be possible to bypass. Essentially visibility is a contract, and sometimes you want or need to go beyond. The language should allow this IMO but make it clear that you are bypassing the contract of the original author. Making things unreachable is just a PITA for no good reason.