Constructive Deconstruction Of Subtyping Discussion

This page is the discussion thread about "Constructive Deconstruction of Subtyping", an article by Alistair Cockburn. The article is available online at http://members.aol.com/humansandt/papers/subtyping.htm. Some comments in LiskovSubstitutionPrinciple, CircleAndEllipseProblem and related pages really belong here, so I ask considerate WikiZens to move them here.

To shorten up my argument, I will refer to Lano subtyping (also called LiskovSubstitution) and Date subtyping, as described in the article. The main point of the article (as I get it) is that Lano subtyping cannot exist in a language that supports reflection. Therefore, it has no realistic usage, as reflection is a very useful programming technique, and every thought about it is a waste of cycles. In other words, Lano subtyping isn't defined in a language with reflection. Date subtyping, however, works perfectly well in reflective environments.

I agree with most of it. In an environment that allows full reflection, no class can be a Lano subtype of another class, for reasons described in the article. However, most of the time only some reflection is needed, and can be controlled. If the programmer is careful enough, she can use reflection and still keep the LiskovSubstitutionPrinciple. It's like using goto's breaks structural programming, and global variables break encapsulation. These are all very powerful programming methods, whose uncontrolled use might break certain mathematical properties of the program, and make it harder to analyze. However, gotos and global variables are essential (loops work with gotos, and classes are global variables). Reflection is essential too, but we didn't yet invent the mechanisms for hiding it and ensuring only good use of it. In the mean while, a programmer can build her program with reflection, and keep subtyping relations the way they were. They will only remain true in the context of her program, or in the sublanguage she works with, and will be broken if someone adds code that breaks them. But doing this, the other programmer makes bad use of the language. The regular definition of Lano subtyping will be broken because the programmer can't control all the methods, but if the programmer limits herself to proper structures and patterns, the LSP will be kept. Lano subtyping can't work in reflective environments, but if you take a similar definition when limiting the methods set, you get a criterion that is as useful. -- AmirLivne

...loops work with gotos.... This is like saying Java has pointers because that's how reference is implemented. Under the hood, maybe. That's why we have the hood. (AmericanCulturalAssumption: the external metal housing that covers the engine of a car. "Bonnet" in British English?) -- TomRossen

I meant that like loops are implemented using gotos (thus hiding the goto from the programmer's control), we need to make new OO structures that will be implemented using reflection, and not let the programmer access full reflection, so he can make Lano subtyping and Date subtyping equal in his program. We don't have these structures yet, so in the meantime we need to think hard while making our programs so that in actual situation we don't break the LSP. After a few years, CStists will figure out the structures and make it easier. -- AmirLivne