public/protected/private is an unnecessary feature
13 points by jez
13 points by jez
I’m willing to look dumb: there isn’t enough here for me to figure out why the article’s claims are true.
But other means could have been used, which reused the existing interface abilities of Simula. For example, Car could specify in the definition of Car that when Car is subclassed, only the fields declared in the base class Vehicle are available to the subclass.
Isn’t that morally an access modifier, very similar in effect to protected (albeit possibly not the same, because at least the java version of public/protected/package visible/private carves up the possibilities in a way that leave some combinations unexpressible: https://lobste.rs/c/4cszvr)?
It’s not 100% clear to me but I think the quoted snippet is saying “other means could have been used [to achieve the goals that inheritance achieved in Simula, namely support for intrusive lists]”
The idea being that linked lists were implemented by subclassing from a superclass ListNode type, and that node type could say “you only get access to these methods to manipulate the list, not to muck with the internals,” which would essentially be a way to have the memory layout be as it would be laid out via single inheritance, but also reuse the interface mechanism (eg, “all my subclasses must access me through this abstract interface”).
The author’s through point is that if your language already has interfaces, why not use that everywhere? Why not have one fewer concept by eliding “per member visibility annotations”?
This is somewhat further clarified in the final link in the post, to another of the author’s posts:
https://catern.com/inheritance.html
If this is not what the author intended then I am also curious like you are.
Car could still have separate interfaces for instantiators and subclasses.
If it’s a separate interface for subclasses, it still seems like it’s an access modifier, albeit a more principled one: this method is available to subclasses, not to unrelated classes.
Like jez, I think the article was saying that there are two “mechanisms” in a language like java:
My understanding is they’re saying you could use the same mechanism (interface) for both operations (view & extend). Exposing an interface for extending an object may not be as flexible as the current mechanisms for subclassing (protected/private/…) but maybe you don’t need that flexibility. The benefit is removing an entire concept & mental burden from the language, and removing the extra syntax too.
I think it’s a cool idea, and I can’t see any immediate problems, but I’ve never tried it so who knows.
As far as I can tell from extensive research, the inventors and users at that time simply didn’t realize that access modifiers duplicated the interface-defining features that were already available: virtual methods and subtyping, which together are sufficient to define interfaces in Simula.
If the article is saying “protected/private are more trouble than they’re worth”, but that they don’t just duplicate existing functionality, I think this paragraph would be open to a lot of criticism.
The author has written a collection of pages critiquing Simula67 and OOP, and this is one of them.
My summary is that if you have user-defined (nominative) data types, modularity, and interfaces, then you don’t need OOP, with its implementation inheritance and public/private/protected class members, to implement data abstraction and encapsulation. OOP implementation inheritance is an old performance hack from the 1960’s, and you get cleaner code by avoiding it. An example that the author takes from the Simula67 manual is implementing an intrusive linked list by inheriting the “next” data member from a ListNode class. Today we use List<T> instead: composition and parameterization instead of implementation inheritance.