Jump to content

Wikipedia:Articles for deletion/Liskov substitution principle

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Bart Jacobs (Leuven) (talk | contribs) at 20:56, 30 June 2020. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Liskov substitution principle (edit | talk | history | protect | delete | links | watch | logs | views) – (View log · Stats)
(Find sources: Google (books · news · scholar · free images · WP refs· FENS · JSTOR · TWL)

I propose to replace this article with a redirect to Behavioral subtyping because substitution terminology, while popular and widespread, is a technically flawed way to discuss behavioral subtyping. As Liskov herself confirms, "technically, it's called behavioral subtyping". Unfortunately, the article uses substitution terminology throughout, so salvaging existing content is nontrivial. There is a section on the Behavioral subtyping page that discusses the problems with substitution terminology. Bart Jacobs (Leuven) (talk) 11:03, 22 June 2020 (UTC)[reply]

  • Oppose. The article Behavioral subtyping looks like a fork of Liskov substitution principle, which was created recently by the OP, Bart Jacobs (Leuven). Before that it was just a redirect from Behavioral subtyping to Liskov substitution principle. And now Bart wants to delete LSP altogether and redirect it to their new article. The thing is, though, the term "Liskov substitution principle" is in widespread use in the IT industry, as one of the five SOLID principles. And the notion that it is incorrect doesn't seem to be supported by sources, other than a throwaway comment by Liskov herself, but rather an attempt to WP:RIGHTGREATWRONGS. (The nominator has stated as a goal that they wish to "erase all traces of the terms "Liskov Substitution Principle" and "substitutability" from the Internet, starting with this article" despite numerous sources using the term). So really, I think the content of Behavioral subtyping should be merged into Liskov substitution principle to leave just one article on the subject, and it should remain at Liskov substitution principle for the reasons above, and because that name is more widely used in book sources than "behavioral subtyping". Thanks  — Amakuru (talk) 11:59, 22 June 2020 (UTC)[reply]
Just want to point out that, besides Liskov's comment, there is an article in the top scientific journal on programming languages[1] (see page 5 in that article), which I cite in Behavioral subtyping. Bart Jacobs (Leuven) (talk) 12:17, 22 June 2020 (UTC)[reply]
By the way: I would be interested in any opposers' opinion on the argument that substitution terminology does not support the case where the supertype is an abstract class: in that case, what does it mean to substitute a subclass object for "a superclass object"? By definition, if the superclass is abstract there can be no objects whose class is the superclass? Anyone with some object-oriented programming background should be able to form an opinion on that argument. Thanks in advance, Bart Jacobs (Leuven) (talk) 13:40, 22 June 2020 (UTC)[reply]
Also: I contest the characterization of Liskov's comment as "throwaway". In the same interview, she points out that the substitution-based rule she mentioned in her keynote address was meant as "an informal rule", and that Jeannette Wing later proposed that they "try to figure out precisely what this means", which led to their joint publication on behavioral subtyping in which they do not use the substitution-based characterization. Also, in the interview itself Liskov does not use substitution-based language to discuss the concepts. I think it's fair to conclude that she believes that the substitution-based characterization is not, in the end, the best possible characterization of behavioral subtyping, to say the least. And I propose that the Wikipedia article on behavioral subtyping (there should be only one) should use the best possible characterization of behavioral subtyping, which is: behavioral subtyping, not LSP. Bart Jacobs (Leuven) (talk) 07:29, 25 June 2020 (UTC)[reply]
I also want to point that the primary source for the LSP article is a keynote address, which is not peer-reviewed, and is written with the goal of pointing out new research directions and sparking discussion, not reporting results. Since it's a speech, there's a different trade-off between concision and precision. The behavioral subtyping article, in contrast, appeared in the top, most thoroughly reviewed scientific journal on programming languages. Bart Jacobs (Leuven) (talk) 07:29, 25 June 2020 (UTC)[reply]
Note: This discussion has been included in the list of Mathematics-related deletion discussions. ~ Amkgp 💬 14:09, 22 June 2020 (UTC)[reply]
Note: This discussion has been included in the list of Computing-related deletion discussions. ~ Amkgp 💬 14:09, 22 June 2020 (UTC)[reply]
  • Keep per Amakuru's investigation and arguments. LSP is widely discussed in OO circles and is obviously a notable topic with much independent referencing--more than enough for a standalone article. That it fits into another OO conceptual hierarchy is fine, but doesn't change the notability of LSP. --{{u|Mark viking}} {Talk} 19:05, 22 June 2020 (UTC)[reply]
Just to clarify: LSP and BS are not separate topics; they are different terms for exactly the same topic. It's just that the term "LSP" is not quite technically accurate. Wouldn't the best approach for dealing with a widely used, but non-optimal term for an important topic be to have it be a redirect to the correct term for this topic? Note, BTW, that I'm not trying to memory-hole the LSP term: there's a section on it on the BS page. Bart Jacobs (Leuven) (talk) 19:17, 22 June 2020 (UTC)[reply]
If you look at for instance, Dhara's thesis page 6, LSP is more closely identified with strong behavioral subtyping. There is also weak behavioral subtyping. Regarding advocating for a better term, WP is meant to be descriptive of reliable sources, not prescriptive, hence the warning against trying to right great wrongs. I think it is reasonable to discuss BS in the LSP article, with due weight. But LSP is a concept taught in OO textbooks; it is not going anywhere and its impact on OO has been strong and lasting. I don't think BS is as widely taught and discussed, at least in non-academic circles. A standalone article makes sense for LSP. --{{u|Mark viking}} {Talk} 20:13, 22 June 2020 (UTC)[reply]
Dhara's thesis page 6 does not say anything about LSP; it refers to Liskov and Wing's 1994 article "A behavioral notion of subtyping", where indeed the notion of behavioral subtyping they propose is the strong variant. But I think the weak versus strong behavioral subtyping distinction is besides the point. The point is that thinking about any flavor of behavioral subtyping in terms of being able to substitute subtype objects for supertype objects is flawed, mainly because 1) it does not support the extremely common case where the supertype is an abstract class that has no objects of its own, and 2) more generally, it suggests comparing the implementation of the supertype with the implementation of the subtype, which is not what you want. It is the specification of the supertype, not its implementation, that matters. — Preceding unsigned comment added by Bart Jacobs (Leuven) (talkcontribs) 21:06, 22 June 2020 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Sandstein 10:39, 30 June 2020 (UTC)[reply]
Does it matter if the more widely used name is technically flawed, and damaging generations of OO students' brains? The flaw is not even subtle or deep. Anyone, please: what does substitutability mean if the superclass is abstract and has no objects of its own? If someone cannot answer that question, are they fit to judge this proposal? Bart Jacobs (Leuven) (talk) 20:54, 30 June 2020 (UTC)[reply]
  1. ^ Leavens, Gary T.; Naumann, David A. (August 2015). "Behavioral subtyping, specification inheritance, and modular reasoning". ACM Transactions on Programming Languages and Systems. 37 (4). doi:10.1145/2766446.