Liskov Substitution: The real meaning of inheritance

The motivating scenario for the Visitor pattern is processing an AST that has polymorphic nodes, to achieve different kinds of processing based on the visiting object, where special cases in that processing are based on the AST node kind.

Even if we have multiple dispatch, the methods we have to write for all the combinations do not disappear.

Additionally, there may actually be a method analogous to accept which performs the recursion.

Suppose that the AST node is so abstract that only it knows where/what its children are. Then you have some:

  ;; accept renamed to recurse; visitor to fun
  ;; visit is funcall

  (defmethod recurse ((node additive-expr) fun)
    (recurse (additive-left-child node))
    (recurse (additive-right-child node))
    (funcall fun node))

(We might want recurse-bottom-up and recurse-top-down.)

If all the AST classes derive from a base that uniformly maintains a list of n children, then this would just be in the base: (for-each-child ch (recurse ch fun)) or whatever.

Suppose we don't want to use a function, but an object (and not to use that object as funcallable). then we need (let's integrate the base class idea also):

  (defmethod recurse ((node ast-node-base) agent)
    (for-each-child ch (recurse ch action-object))
    (do-action node agent))   ;; basically (visit node visitor)

Now we have a myriad method specializations of do-action.

  (defmethod do-action ((node additive-expr) (agent printer))
    ...)

  (defmethod do-action ((node if-statement) (agent printer))
    ...)

By doing it this way, we get rid of a lambda shim. Instead of:

  (let ((printer (make-printer *std-output*)))
    (recurse ast (lambda (node) (do-action node printer))))

we can just have:

  (let ((printer (make-printer *std-output*)))
    (recurse ast printer))

It's only not the Visitor Pattern because I used recurse instead of accept, do-action instead of visit, and agent instead of visitor.

One example for when you might want something like a class hierarchy is something like a graph/tree structure, where you have lots of objects of different types and different attributes carrying references to each other that are not narrowly typed. You then have a set of operations that mostly do not care about the narrow types, and other operations that do care. You have things that behave mostly the same with small variations, in many cases.

> and each of them would have those attributes on them that characterize each of them respectively (and those attributes would not be shared - if they were, such shared attributes would go on the User object)

Suppose you want to compute a price for display, but its computation is different for Students and Employees. The display doesn't care if it's a Student or an Employee, it doesn't want to need to know if it's a Student or an Employee, it just wants the correct value computed. It can't just be a simple shared attribute. At some point you will need to make that distinction, whether it's a method, a conditional, or some other transform. It's not obvious how your solution could solve this more elegantly.

> which is insane

Not at all, in my view this kind of pattern matching is generally preferable over dynamic dispatch with methods, because you see what can happen in all cases, at a glance. But again, you do not even have a contrived example where you would need dynamic dispatch in the first place, so naturally its use not obvious.

Your price could simply be an interface that both Student and Employee implements, and at the call site, you simply call foo.calculatePrice - Student will calculate it one way and Employee another, there is zero need for inheritance, or for the call site to know which object is which of the two types - all it needs to know is it has the calcultePrice interface.

I also prefer pattern matching over dynamic dispatch. But I maintain that conjuring up attributes out of thin air (which is 100% what you're doing when your function accepts one type, and then inside, conjures up another, that has additional attributes from the input!) is insane. There are so many good reasons not to want to do this I don't even know where to begin. For one, it's a huge footgun for when you add another type that inherits - the compiler will NOT force you to add new branches to cover that case, even though you may want it to. Also, such "reusable" if this then do this else do that methods when allowed to propagate through the stack means every function is no longer a function, it's actually *n functions, so ease of grokking and maintainability goes out the window. It's much better to relegate such ifs to the edges of the system (eg the http resource endpoint layer) and from there call methods that operate on what you want them to operate on, and do not require ifs.

I pointed you to a specific book i.e. OOSC2 and three specific chapters in it (to start with) which explain the concepts well with examples you asked for. How much more specific can one get? If you already know contracts then it should be easy to translate the concepts to any language of your choice. Meyer provides a thorough rationale and is extremely detailed in his examples. Furthermore, i also pointed you to one of the largest and commercially most successful class library and application framework (i.e. MFC) where you can see classic OOD/OOP (including upcalls/downcalls) in action; and yet you say i am "speaking in generalities"! It seems you are not willing to read/study but expect a couple of paragraphs to enlighten everything, which is not going to happen.

Eg: Base.method() has {pre1} and {post1} as contracts. Derived.method() has {pre2} and {post2} as contracts. What should be the relationship between {pre2}&{pre1} and {post2}&{post1} to enforce proper subtyping?

> This is a common frustration I have with OOP discourse, it tends to be really up-in-the-air and not grounded in concrete specifics

It is not up-in-the-air when ideas and specific books by authors like Bertrand Meyer and Barbara Liskov (both researchers and practitioners) are being pointed out. Trying to simplify their concepts into a couple of paragraphs would invariably miss important nuances and lead to misinterpretations (the bane of most HN discussions based on trivial articles/blog posts). Hence it is better they are studied directly and then we can have a discussion if you would like.

> Meanwhile, users suffer in ways that just don't happen with typeclass-based polymorphism, and none of this discourse is required in my world. So why should I not recommend everyone use typeclass-based polymorphism?

Sure, there are other types of polymorphisms which can be better in certain scenarios. But that is not under discussion here; we are talking about "traditional" dynamic runtime dispatch based polymorphism which is far easier to understand and implement even in small languages like C.

> No, being too flexible is a weakness, not a strength. At scale, rigorous discipline enforced by tooling is required.

Flexibility increases your "design space" and hence never a weakness. Rigorous discipline is needed throughout development but tooling can only do so much.

> In particular, invariants like "no downcalls" or "no upcalls" should 100% be enforced by automation.

This depends on the concept you are trying to express and cannot be the same in all scenarios (except for direct ones like "interface implementation").

> I'd rather not?

Well, you did ask for a concrete example and i showed you MFC apps.

> This sounds really bad to me at scale and under pressure.

Saying something is "bad" or "spaghetti" without understanding the design concepts behind the implementation is wrong. MFC is one the largest and most successful application frameworks in the industry and has proven itself in all sorts of applications at scale; studying it teaches one lots of OOD/OOP techniques (good/bad/ugly) needed in real-life industry apps.

At work we sadly have to implement very OOP-y standards with all the bullshit that entails. 11 levels of inheritance with overrides all over the place sure isn't fun to deal with.

But for things I do myself I use objects and interfaces strictly as a tool to solve specific problems, not as the overall program structure.

Most of the time you just need to turn some bits into other bits with a function, no need to overcomplicate things.

The question of if a square is a rectangle or a rectangle is a square is the sort of thing that comes from OOP brain-rot. They're just data, and their "isa" relationship is likely not even relevant to the problem you're actually trying to solve, like displaying them onscreen.

A "square" could be a function that makes a rectangle out of a single float. A "rectangle" could be a function that produces a polygon. The concepts need not be modeled as types or objects at all.

It depends on the actual use case.