Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109319
MIME-Version: 1.0
References: <1b781e1e-3f27-485b-ab47-5eeaf9496548@www.fastmail.com>
 <CAF+90c-UoKFF4tWZ-PqX5iMbvXzENs1SLVS1uEz67O-Uj8FsYg@mail.gmail.com>
 <CAOWwgp=MEA6X7NdRpid3CvpKrrYq42oBJqsC-22=xr5K40heig@mail.gmail.com> <56f4f7bf-6086-4e10-addb-aba93ba23c5e@www.fastmail.com>
In-Reply-To: <56f4f7bf-6086-4e10-addb-aba93ba23c5e@www.fastmail.com>
Date: Wed, 25 Mar 2020 21:36:54 -0500
Message-ID: <CAJmjfvULh_M-Nm_dO=kpO95HU70Zu4UPUzfHDKyBnbL+U7-jkg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
From: jakob@givoni.dk (Jakob Givoni)

Hi Larry and Nicolas,

On Wed, Mar 25, 2020 at 9:24 AM Larry Garfield <larry@garfieldtech.com> wrote:

> > I'd like to propose something on the topic.
> > I'm adding object literals to the mix because that's another feature of the
> > language that we're missing a lot IMHO.
> > Actually, there is one existing syntax for objects: (object) [...]
>
> [...]
>
> 2) What's its order of execution with the constructor?  Vis, does the constructor run after __create or before?  Does __construct get any parameters passed to it?

That's the interesting question, though there's probably not any
sensible answer that works for all use cases. However, if this kind of
object casting (object literal notation) was limited to a certain
(extendable) internal class (SPL Struct?), we could have just a final
public function __construct(array $properties = []) that then
delegates the validation to an abstract __validation() method. Would
that at least be a useful alternative to constructor promotion?

> In that syntax, you have to remember which one comes first.  There's no indication for the casual reader why
>
> public private $property;
>
> and
>
> private public $property;

I'm wondering - are there any use cases where you would have private
read and public write?

If not, maybe this issue can be simplified by adding (f.ex.)
"semiprivate" and "semiprotected" attribute keywords, the idea being
that they give readonly access to the anything else.

Though I think it would be great to have a nice, gracefully extensible
attribute syntax, maybe it's not necessary to fight over that for this
particular issue?

> Either way, what matters is who is in charge of dealing with the issues
> this might create. In both ways, what matters is that the original author
> won't be bothered for things that are not its responsibility. "I broke your
> app because you messed up with that private property on a class I
> authored?" no my problem. About final, I usually prefer using the "@final"
> annotation: it expressed exactly what I need to express as the author of
> the code: "if you extend, you're on your own - but I'm not dictating what
> you can/can't do either".
>
> I think this reasoning applies to my view on immutability :)

:-)
I can relate to that in general.
Though for immutability, I'm not so sure anymore...