Re-forwarding to the list (please stop replying to me in private, thanks). Also re-answering but I will stop there because that's too much digression for a partial quote of my initial message.
On Wed, Apr 28, 2021 at 5:30 PM Tony Marston <tonymars...@hotmail.com> wrote: > On 28/04/2021 14:30, Guilliam Xavier wrote: > > Forwarding to the list, and answering: > > > > On Wed, Apr 28, 2021 at 9:51 AM Tony Marston <tonymars...@hotmail.com> > > wrote: > > > >> On 27/04/2021 17:22, Guilliam Xavier wrote: > >>> On Sat, Apr 24, 2021 at 12:55 PM Saif Eddin Gmati < > azj...@protonmail.com > >>> > >>> wrote: > >>> > >>> > >>> To me the first sentence of the RFC is debatable: > >>> > >>>> The purpose of inheritance is code reuse, for when you have a class > that > >>>> shares common functionality, and you want others to be able to extend > it > >>>> and make use of this functionality in their own class. > >>> > >>> That sounds like [abstract] base classes, which certainly permit that, > >> but > >>> I wouldn't state that "the purpose" of [designing] class hierarchies is > >>> "code reuse", which can also (better?) be achieved with traits or even > >>> simply composition > >> > >> I completely disagree that the first sentence of that RFC is debatable > >> as I consider it to be totally accurate. When you use inheritance via > >> the 'extends' keyword then every method in the superclass is shared by > >> the subclass. In the subclass you have the option to override the > >> implementation of any method in the superclass, or you can add new > >> methods of your own. > > > > > > But does that necessarily mean that "The purpose of inheritance is code > > reuse"? > > Can you show me any description of OOP which says that the purpose of > inheritance is anything other than code reuse? I suspect it won't convince you but you can find quotes like: "The point of inheritance is to take advantage of polymorphic behavior NOT to reuse code, and people miss that, they see inheritance as a cheap way to add behavior to a class." (not that I endorse it absolutely, but that's an example of different opinion). What other purose could > it possibly serve? > Modeling a problem domain? Enforcing a contract? > > This superclass may be abstract, but it need not > >> be. The methods it contains may be abstract, but they need not be. > >> > > > > I didn't say that they need (the brackets meant "optionally"). And does > it > > really matter actually? > > Yes. If you inherit any abstract methods you are not actually inheriting > anything. Not only do you have to manually define in the subclass any > method which is defined as abstract, you also have to provide the > implementation. > My bad, I should have inserted the reply one sentence earlier: I was referring to "[abstract] base classes" (from my original quote), not abstract methods. Of course if the goal is to share implementation there must be concrete methods in the base class... > >> According to the Gang of Four the way to avoid the problems caused by > >> the overuse of inheritance is to only inherit from an abstract class, > >> which is precise what I do. I am famous for having an abstract table > >> class in my framework which contains hundreds of methods and thousands > >> of lines of code, and because each of my 400 concrete table classes > >> inherits from the same abstract table class that is a LOT of code which > >> is shared. This abstract table class also allows me to use the Template > >> Method Pattern (which is mentioned in the Gang of Four book) so that all > >> the invariant methods are defined in the abstract class which means that > >> each subclass need only contain the variable "hook" methods for which it > >> needs to provide an implementation. > >> > > > > Well, PHP is flexible. I have seen many combinations of (one or several > of) > > interface, [abstract] class, trait, composition... depending on the > context. > > The fact that there are now several ways of reusing code does not > detract from the original statement that "The purpose of inheritance is > code reuse". > See above, plus a quick web search for things like "inheritance misuse" or "class SplStack extends SplDoublyLinkedList" I think shows it's a controversial subject (hence "debatable" at least). > >> When you say that code reuse can be better achieved with traits or > >> object composition I have to disagree. > > > > > > I said "also (better?)", not just "better". But one can think "no" to > > "better?" ;) > > > > > > Object composition is used only > >> by those idiots who overuse inheritance, > > In the GoF book on design patterns, which was first published in 1995, > it quite clearly stated that any problems emanating from inheritance > were causes by its overuse, and that a solution would be to only ever > inherit from abstract classes. "class Stack extends AbstractList" is still wrong. If people are still overusing inheritance > 25 years later and ignoring the advice given by the Gang of Four then I > feel justified in calling them idiots. > :/ > > and there is no evidence that > >> traits are "better" than inheritance. > > > >> By the way, is there evidence to the contrary? (genuine question) > > Until somebody does a comparison of all the different ways in which code > can be shared there can never be a definitive answer. > Agreed. > >> Inheritance, when used sensibly, is still the best way to share code. > >> > > > > Your opinion, maybe not unanimity (nor absolute truth). > > The GOF book says so, and it also says that the Template Method Pattern > - which can only be used through inheritance - is a fundamental > technique for code reuse. Are The GoF Book opinions (still) unanimity? Also, did PHP traits exist in 1994? (rhetorical questions) (and BTW, I know, composition did already exist, but not the point) In my humble opinion any method of code reuse > which does not allow the Template Method Pattern is automatically inferior. > You said it: "in [your] humble opinion" :) I have mine too. Anyone can (obviously). More importantly, even if I were to agree that "inheritance" be the best method of "code reuse" (and I have to admit it is widely used like that), I still wouldn't state that that's "the [absolute and only] purpose" of it. > Regards, > > Tony Marston > Regards, -- Guilliam Xavier
