3 ms·

> programming masses, some evil (bleep) Too harsh. Logic is hard for humans. Evolution has trained us to take lots of mental shortcuts, not to be perfect calcu

> programming masses, some evil (bleep) Too harsh. Logic is hard for humans. Evolution has trained us to take lots of mental shortcuts, not to be perfect calculating machines. Even the most technically competent people rely on their intuition. What differentiates them from the rest of us is that they have trained their intuition to make it more reliable [0]. It's the job of a language designer to arrange things so that intuition doesn't mislead programmers regarding the meaning of language features. Before proposing a new feature, the designer must anticipate how programmers will think about code that uses this feature, and there better not be a mismatch between what programmers think the code means and what the code actually means. > A inherits B, if I try to actually use it as a B, it promises to work. There's nothing wrong with implementation inheritance per se [1]. It addresses a very common use case: you have a thing Foo, and you want to produce another thing Bar that's similar to Foo, with minor changes here and there. This describes accurately how many things work in real life. However, you can't assume that Bar can always be used where Foo is expected. Those “minor changes here and there” might have rendered Bar incompatible with Foo. Hence, “inheritance is not subtyping”. As stated above, it's the job of a language designer to anticipate this. [0] https://terrytao.wordpress.com/career-advice/there%E2%80%99s-more-to-mathematics-than-rigour-and-proofs/ https://terrytao.wordpress.com/career-advice/there%E2%80%99s... [1] Other than the lack of mathematical elegance, but few things are mathematically elegant in life.

eli_gottlieb 10y ago
>Hence, “inheritance is not subtyping”. As stated above, it's the job of a language designer to anticipate this. Yes, it is their job, by not allowing subclasses to be used as subtypes.
- catnaroek 10y ago
  Some subclasses can be safely used as subtypes. For example, those that meet the following two conditions: (0) Not directly mutating superclass fields. (Reading them is fine.) (1) Not overriding non-abstract methods of the superclass.
  - dragonwriter 10y ago
    If classes are types, subsclasses should be subtypes -- so the above restrictions should just be applied to subclass relationships. One could also have an non-subclassing mechanism of implementation sharing, that might be declared something like this: class Related does (method1, method2) like Base; or class Related does all except (method3) like Base;
    - catnaroek 10y ago
      That syntax is too heavyweight (IMO). AFAICT, most of the time, when people use inheritance, they don't want to define perfect subtypes. They just want to reuse as much already implemented behavior as possible.
      - dragonwriter 10y ago
        > That syntax is too heavyweight (IMO). I'd be fine with something more compact for the default case of "steal all behavior except what is explicitly overridden", such as: class Related like Base;
        catnaroek 10y ago
        (0) Do you have a use case for cherry-picking which methods are inherited? If not, it seems like too much complexity for me. (1) Do you think there would still be a use case for “extends”? If not, I'd rather drop it as well.
        dragonwriter 10y ago
        > Do you have a use case for cherry-picking which methods are inherited? The most obvious is that it makes intent explicit in the case of multiple similarity (I prefer "similarity" to "inheritance" for non-subtyping implementation reuse.) It might in some cases make sense to do this on an interface rather than (or in addition to) single method level; there's probably a lot to work out in the ergonomics of non-subtyping implementation reuse. > Do you think there would still be a use case for “extends”? Sure, classical subclassing (subtyping with implementation sharing) remains an important use case. It might be desirable to statically verify certain guarantees (some have been suggested in at least one subthread of this thread by another poster) to assure that the subtyping is reasonable, but even without such verification the use case remains important.
- naasking 10y ago
  > Yes, it is their job, by not allowing subclasses to be used as subtypes. That's probably too extreme. Subtyping should just be explicitly declared rather than implicit when subclassing.

eli_gottlieb 10y ago

>Hence, “inheritance is not subtyping”. As stated above, it's the job of a language designer to anticipate this. Yes, it is their job, by not allowing subclasses to be used as subtypes.

catnaroek 10y ago
Some subclasses can be safely used as subtypes. For example, those that meet the following two conditions: (0) Not directly mutating superclass fields. (Reading them is fine.) (1) Not overriding non-abstract methods of the superclass.
- dragonwriter 10y ago
  If classes are types, subsclasses should be subtypes -- so the above restrictions should just be applied to subclass relationships. One could also have an non-subclassing mechanism of implementation sharing, that might be declared something like this: class Related does (method1, method2) like Base; or class Related does all except (method3) like Base;
  - catnaroek 10y ago
    That syntax is too heavyweight (IMO). AFAICT, most of the time, when people use inheritance, they don't want to define perfect subtypes. They just want to reuse as much already implemented behavior as possible.
    - dragonwriter 10y ago
      > That syntax is too heavyweight (IMO). I'd be fine with something more compact for the default case of "steal all behavior except what is explicitly overridden", such as: class Related like Base;
      - catnaroek 10y ago
        (0) Do you have a use case for cherry-picking which methods are inherited? If not, it seems like too much complexity for me. (1) Do you think there would still be a use case for “extends”? If not, I'd rather drop it as well.
        dragonwriter 10y ago
        > Do you have a use case for cherry-picking which methods are inherited? The most obvious is that it makes intent explicit in the case of multiple similarity (I prefer "similarity" to "inheritance" for non-subtyping implementation reuse.) It might in some cases make sense to do this on an interface rather than (or in addition to) single method level; there's probably a lot to work out in the ergonomics of non-subtyping implementation reuse. > Do you think there would still be a use case for “extends”? Sure, classical subclassing (subtyping with implementation sharing) remains an important use case. It might be desirable to statically verify certain guarantees (some have been suggested in at least one subthread of this thread by another poster) to assure that the subtyping is reasonable, but even without such verification the use case remains important.
naasking 10y ago
> Yes, it is their job, by not allowing subclasses to be used as subtypes. That's probably too extreme. Subtyping should just be explicitly declared rather than implicit when subclassing.