I've been thinking about inheritance a lot and need to braindump on it. Standard caveats: this is unpolished, first draft thoughts, not an expert, etc etc etc So, like, why, fundamentally, is inheritance so dangerous? And why is it so SUBTLY dangerous?https://twitter.com/johnregehr/status/1102777049599500289 …
-
Show this thread
-
I really like the essay "Why Inheritance Never Made Any Sense" (https://www.sicpers.info/2018/03/why-inheritance-never-made-any-sense/ … ), which defines 3 "uses" of inheritance: 1. Ontological inheritance: "A is a B" 2. ADT inheritance: "A can be used as a B" 3. Implementation inheritance: "A has the same code as B"
4 replies 6 retweets 47 likesShow this thread -
Replying to @hillelogram
Inheritance is about defining functions using partial information. Subclasses incrementally refine what information is available. Instantiating a class is declaring that this information is all there is, and the instance type is the least fixed point.
1 reply 0 retweets 0 likes -
Replying to @Ngnghm @hillelogram
The square/rectangle problem is solved by most classes NOT defining slots, but only reader functions just like in CLOS. Only for concrete classes (Java "final") would you (auto) declare unfilled readers as slots. Or you could dispense with classes and keep refining prototypes.
1 reply 0 retweets 0 likes
Nix and Jsonnet also proved that prototype inheritance works beautifully in a pure lazy functional language. A proper type system for that style must support merging of slot sets, though, so multiple row variables with associative commutative unification. As in Ur, Ermine.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
Read my blog!