Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115876
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CAEZPtU6yMvkAEdhopUm2o8+0U=iBOm9N5+wmYL6zeNq1e2xMRQ@mail.gmail.com>
Date: Fri, 27 Aug 2021 01:19:04 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9F149124-AE06-4F25-A410-12C534635A37@newclarity.net>
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
 <CAESVnVqMfxSZxG1+k+_o+HZ1B7QbH=wDeMTQm8R-Ok_bEyqSRA@mail.gmail.com>
 <CAF+90c-J7skECnr7TE5f5twBNRArhAh3xuKVjdGqq3HsOZrnog@mail.gmail.com>
 <c4db0e87-e673-03b8-66c8-87da0552c13c@gmail.com>
 <CAEZPtU6yMvkAEdhopUm2o8+0U=iBOm9N5+wmYL6zeNq1e2xMRQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties
From: mike@newclarity.net (Mike Schinkel)

> On Aug 26, 2021, at 11:02 PM, Pierre Joye <pierre.php@gmail.com> =
wrote:
> I don't know how others feel about it, I think most want to go the
> path to (2) and a more strict, if not almost fully strict PHP. Core
> devs to simplify the engine, users to allow them easier checks and
> safety in their frameworks or libs. End user don't really bother as
> far as I can see. We may have to decide once the long term vision for
> PHP and then do the changes accordingly, and more importantly, with
> consistency.

I tend to concur that path (2) would provide the better outcome.=20

However, eliminating dynamic variables would be eliminating the ability =
to simulate a(t least one) language feature that some (many?) people =
have been using dynamic variables to simulate. Maybe as part of =
deprecation of dynamic variables we should also consider adding =
this(ese) feature(s) to the PHP language?

There are two approaches I can envision, Both would better enable the =
S.O.L.I.D. "open-closed" principle in PHP. =20

1.) Allow PHP class declaration across multiple files =E2=80=94 A =
use-case for this is what I think is effectively the command dispatcher =
pattern where properties contain instances of classes that might be =
contributed by 3rd party code to allow those developers to access the =
instances by named property: e.g. $cms->map->display() where $map is =
added by a 3rd party library to the class for the $cms instance before =
$cms is instantiated.  See:

https://gist.github.com/mikeschinkel/ed4f9594c105dae7371bfce413399948

Some might view this as "monkey patching" but I view it as a more =
structured approach, like C# partial classes.

2.) Allow trait usage for a class from another file =E2=80=94 This is =
just a slightly different spin on #1. See:

https://gist.github.com/mikeschinkel/5b433532dc54adf53f5b239c8086fd63

Each approach has its own pros and cons but it probably depends on which =
would be easier and more performant to implement.

-Mike