Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114214
Message-ID: <D5E743D4-CC81-44C6-90F7-BDDBDF40F831@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F22E0BD4-FFC9-4215-9451-591E2739078E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Date: Tue, 27 Apr 2021 17:47:29 -0400
In-Reply-To: <CAPKYkKx77Q0WFvJdQ7ag9wvLNYM5r9xkrPRWER1pHBr8KH_08Q@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: Chase Peeler <chasepeeler@gmail.com>
References: <V7C5-r6tzKmxjhPnvy9gtfdMtxkj0z_PJphaehaqcPsOLX0pEKtGU4A8EuSKyS-cbZl5HPVA2ejXCuXXOfOksH9VACGOKT3awRsr9aSNIg8=@protonmail.com>
 <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org>
 <CAJpLVh2UybGgAqhfAGQ=kKQ-qvmG68HWKaUJXOwPv7DgEbAdKw@mail.gmail.com>
 <179049b1475.11134368b213512.254739612773841999@void.tn>
 <CAJpLVh0pz_WopKza=XXqPrvS4bQZhWom1FQ6QLW-fbC-8JHkrA@mail.gmail.com>
 <CADyq6sLtgNkyM-qQcwRY8mMOxnkrz_9qeG6XK2uDBqsh=smMtg@mail.gmail.com>
 <CAJpLVh3C63FTUzWusVOp5JOGpuKbOYi0WovYvNFv20npNJFh3g@mail.gmail.com>
 <b4276d92-4856-4222-8c34-55b1422030c5@www.fastmail.com>
 <EA268E52-2954-40DE-B3CC-D447A4983887@cschneid.com>
 <CAC5V6gghaZv=MCQz+FWNDAMUj2KorjvL_tNO+DNAPT0ioycpSA@mail.gmail.com>
 <CA+p1FabuUDUzMkEhwyy0BJVd71N=6ubn5pEJNh8VkE8D9rJhow@mail.gmail.com>
 <722ed544-69e3-3be4-f828-185914617228@processus.org>
 <CA+p1FaZjWc+cMrfWkGP5LCmv6YOKF3h7dY_yYXxCmfUpRfp4fw@mail.gmail.com>
 <CAAKU0u=MrTOCME-omM0Vh_j2Wwu89V6+gWp8eJj19MweJ00vHw@mail.gmail.com>
 <CAPKYkKyRWmpByUrtjJ7U67gdj8a7eM0kE-qxKPnLLEsVFQkZ3w@mail.gmail.com>
 <CAJpLVh37Lq44sDSKDCqBk1HKtML1dyu0v4+V8LBSr8Hnu67KoQ@mail.gmail.com>
 <CAPKYkKx77Q0WFvJdQ7ag9wvLNYM5r9xkrPRWER1pHBr8KH_08Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_F22E0BD4-FFC9-4215-9451-591E2739078E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Apr 27, 2021, at 3:07 PM, Chase Peeler <chasepeeler@gmail.com> =
wrote:
>=20
> As someone mentioned above, maybe they want to just add some logging
> capabilities to maybe.
> class MyMaybe extends Maybe {
>  protected $logger;
>  public function setLogger($logger){ $this->logger =3D $logger; }
>  public function value(){
>     if(null !=3D=3D $this->logger){ $this->logger->log("getting =
value"); }
>     return parent::value();
>  }
> }

That is one argument. But maybe that argument points to the need for a =
different feature, one that could be considered for PHP instead of =
limiting the freedom of the library/framework author to decide how their =
code will be used?

We could add an Events feature that would allow users of a class to run =
a closure before or after every time a class' methods are run?  People =
often suggest that attributes can be used to implement such features but =
then attributes can only be added by the author of the class, not =
injected by users of the class.

Imagine if something like the following existed (I just spitballed the =
syntax as a straw man suggestion; I doubt an actual events feature would =
look much like this after requirements were fleshed out):

/*=20
 * Attach an event to run *after* every time the Maybe class was =
instantiated
 */
\PHP\Events::after( [ Maybe::class, "__construct" ], func($context){
    // Attach a property to the instance that would only be visible =
inside of events
    $context->logger =3D MyLogger::get();
})

/*=20
 * Attach an event to run *before* every time the value() method was =
called an a Maybe instance
 */
\PHP\Events::before( [ Maybe::class, "value" ], func($context){
    // Call log() on the attached $logger property
    $context->logger->log("getting value");
})

/*=20
 * Your logger class
 */
class MyLogger {
   private static $logger;
   public static function set($logger){
     self::$logger =3D $logger;
   }
   public static function get(){
     if (!isset(self::$logger)) {
        self::$logger =3D new MyLogger();
     }
     return $logger;
   }
   public static function log($msg){
     printf( "$1\n", $msg );
   }
}

/*=20
 * Example usage code
 */
$m =3D new Maybe(1)
echo $m->value();   // echos "getting value\n1"


In my view this would be more consistent with the open-closed principle =
of S.O.L.I.D. because it would allow a developer to augment classes in =
libraries and frameworks that hardcode instantiate =E2=80=94 do not just =
dependency injection =E2=80=94 something you cannot do with mere =
subclassing.

I know this suggestion is off-topic for this thread, but I introduce to =
point out at least some of the objections to `sealed` could addressed =
better by new language features. =20

SO IF people are interested in discussing this specific language feature =
more, PLEASE break this off into a different thread.

-Mike
P.S. Also, I admit I did what I hate when other people do it; I focused =
on your example that you used to illustrate a general principle and I =
addressed that example only, not your general concern. But I only did so =
because other features would better address that specific example. =20

Do you have other examples that would illustrate why you might want to =
extend a Maybe class that could not be handled with events?


--Apple-Mail=_F22E0BD4-FFC9-4215-9451-591E2739078E--