Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114234
MIME-Version: 1.0
References: <V7C5-r6tzKmxjhPnvy9gtfdMtxkj0z_PJphaehaqcPsOLX0pEKtGU4A8EuSKyS-cbZl5HPVA2ejXCuXXOfOksH9VACGOKT3awRsr9aSNIg8=@protonmail.com>
 <CAC5V6gjW4hhEx=m6RuFoR+D5QCiNbHWyAH5Wd6-nwbH7noxFmg@mail.gmail.com> <AM6PR01MB53369F48110B79A241E74C6ABB409@AM6PR01MB5336.eurprd01.prod.exchangelabs.com>
In-Reply-To: <AM6PR01MB53369F48110B79A241E74C6ABB409@AM6PR01MB5336.eurprd01.prod.exchangelabs.com>
Date: Wed, 28 Apr 2021 15:30:13 +0200
Message-ID: <CAC5V6giZ-LaSbg0-eQZoqPxDBonsSbococNLNg8YAsgs8o6R2Q@mail.gmail.com>
To: Tony Marston <tonymarston@hotmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000080b78105c10861c2"
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: guilliam.xavier@gmail.com (Guilliam Xavier)

--00000000000080b78105c10861c2
Content-Type: text/plain; charset="UTF-8"

Forwarding to the list, and answering:

On Wed, Apr 28, 2021 at 9:51 AM Tony Marston <tonymarston@hotmail.com>
wrote:

> On 27/04/2021 17:22, Guilliam Xavier wrote:
> > On Sat, Apr 24, 2021 at 12:55 PM Saif Eddin Gmati <azjezz@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"?

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?


> 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.


> 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,


:/

and there is no evidence that
> traits are "better" than inheritance.
>

By the way, is there evidence to the contrary? (genuine question)


> Inheritance, when used sensibly, is still the best way to share code.
>

Your opinion, maybe not unanimity (nor absolute truth).


> Regards,
>
> Tony Marston
>
>
Regards,

-- 
Guilliam Xavier

--00000000000080b78105c10861c2--