4 ms·

Some subclasses can be safely used as subtypes. For example, those that meet the following two conditions: (0) Not directly mutating superclass fields. (Readin

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.
        catnaroek 10y ago
        > The most obvious is that it makes intent explicit in the case of multiple similarity Keep in mind that similarity is explicitly intended to be a quick-n-dirty form of code reuse. If the programmer has enough time to refactor the code, he or she should probably factor out the common parts, and then use proper (subtyping) inheritance. In view of this, I don't think making similarity overly complicated is a good idea. > Sure, classical subclassing (...) remains an important use case. (...) even without such verification the use case remains important. It's precisely the lack of such verification that destroys the guarantees you can extract from Liskov's substitution principle.
        dragonwriter 10y ago
        > If the programmer has enough time to refactor the code, he or she should probably factor out the common parts, and then use proper (subtyping) inheritance. I do see the attraction of the idea that all implementation sharing ultimately reflects something that can be expressed through a subtyping hierarchy adhering to the LSP, but I'm not 100% convinced that it is the case. Absent certainty on that point, I'd like to have a model of similarity that is workable when viewed as an ultimate, rather than interim, model. Also, I think that this kind of explicitness (with similar syntax) is desirable for subtyping inheritance in languages that support multiple inheritance, so it keeps similarity in line with inheritance, with the distinction only in the relationship being expressed (so, while it may make similarity more complex, it keeps the whole language more simple but explicit.) > It's precisely the lack of such verification that destroys the guarantees you can extract from Liskov's substitution principle. I agree that static verification of sanity in subtyping inheritance reduces the problem of LSP violations (as, frankly, does non-static verification, such as testing frameworks using subtype relationships to automatically apply tests for supertypes to subtypes.) The degree and type of verification (as well as other details like cherrypicking and support for multiple similarity) that is appropriate for these type of things really depends on the language. Extending Perl or Python (dynamic languages with multiple inheritance) to support similarity alongside inheritance is probably going to favor different tradeoffs than extending Java (static with single inheritance) to support similarity.
    - deleted 10y ago
      [deleted]
  - eli_gottlieb 10y ago
    Very true. Mixin delegation is the thing we actually want here.
- naasking 10y ago
  > If classes are types, subsclasses should be subtypes Disagree. C++ added private inheritance for a good reason. There are scenarios when you want to inherit part of an implementation, but override some of the behaviour for code reuse without inheriting any kind of subtyping relationship. There are also scenarios where you want to declare a subtype without inheriting any parent behaviour. So ultimately subtyping is distinct from subclassing.

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.
      - catnaroek 10y ago
        > The most obvious is that it makes intent explicit in the case of multiple similarity Keep in mind that similarity is explicitly intended to be a quick-n-dirty form of code reuse. If the programmer has enough time to refactor the code, he or she should probably factor out the common parts, and then use proper (subtyping) inheritance. In view of this, I don't think making similarity overly complicated is a good idea. > Sure, classical subclassing (...) remains an important use case. (...) even without such verification the use case remains important. It's precisely the lack of such verification that destroys the guarantees you can extract from Liskov's substitution principle.
        dragonwriter 10y ago
        > If the programmer has enough time to refactor the code, he or she should probably factor out the common parts, and then use proper (subtyping) inheritance. I do see the attraction of the idea that all implementation sharing ultimately reflects something that can be expressed through a subtyping hierarchy adhering to the LSP, but I'm not 100% convinced that it is the case. Absent certainty on that point, I'd like to have a model of similarity that is workable when viewed as an ultimate, rather than interim, model. Also, I think that this kind of explicitness (with similar syntax) is desirable for subtyping inheritance in languages that support multiple inheritance, so it keeps similarity in line with inheritance, with the distinction only in the relationship being expressed (so, while it may make similarity more complex, it keeps the whole language more simple but explicit.) > It's precisely the lack of such verification that destroys the guarantees you can extract from Liskov's substitution principle. I agree that static verification of sanity in subtyping inheritance reduces the problem of LSP violations (as, frankly, does non-static verification, such as testing frameworks using subtype relationships to automatically apply tests for supertypes to subtypes.) The degree and type of verification (as well as other details like cherrypicking and support for multiple similarity) that is appropriate for these type of things really depends on the language. Extending Perl or Python (dynamic languages with multiple inheritance) to support similarity alongside inheritance is probably going to favor different tradeoffs than extending Java (static with single inheritance) to support similarity.
  - deleted 10y ago
    [deleted]
- eli_gottlieb 10y ago
  Very true. Mixin delegation is the thing we actually want here.
naasking 10y ago
> If classes are types, subsclasses should be subtypes Disagree. C++ added private inheritance for a good reason. There are scenarios when you want to inherit part of an implementation, but override some of the behaviour for code reuse without inheriting any kind of subtyping relationship. There are also scenarios where you want to declare a subtype without inheriting any parent behaviour. So ultimately subtyping is distinct from subclassing.