[GvR] > [Ping] > > If i may hazard a guess, i'd imagine that Jim's answer would simply be > > that inheritance (of implementation) doesn't imply subtyping, and > > subtyping doesn't imply inheritance. > > Well, yes, of course. But I strongly believe that in *most* cases, > inheritance and subtyping go hand in hand. I'd rather invent a > mechanism to deal with the exceptions rather than invent two parallel > mechanisms that must both be deployed separately to get the full > benefit out of them. One exception being to able to declare conformance to an interface after-the-fact in some sweet way. > > > Agreeing on an ontology seems the hardest part to me. > > > > Indeed. One of the advantages of separating inheritance and subtyping > > is that this can give you a bit more flexibility in setting up the > > ontology, which may make it easier to settle on something good. > > Really? Given that there are no inheritance relationships between the > existing built-in types, I would think that you could define an > ontology consisting entirely of abstract types, and then graft the > concrete types on it. I don't see what having separate interfaces > would buy you. But perhaps you can give an example that shows your > point? > E.g. my ideas of declaring partial conformance and of super-interfaces identified as a base-interface plus a subset of signatures do not fit so well in a just-abstract-classes model. But OTOH I insist, IMO, given how python code is written now, they would be handy although complex. regards.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4