Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109286
MIME-Version: 1.0
References: <1b781e1e-3f27-485b-ab47-5eeaf9496548@www.fastmail.com> <CAF+90c-UoKFF4tWZ-PqX5iMbvXzENs1SLVS1uEz67O-Uj8FsYg@mail.gmail.com>
In-Reply-To: <CAF+90c-UoKFF4tWZ-PqX5iMbvXzENs1SLVS1uEz67O-Uj8FsYg@mail.gmail.com>
Date: Wed, 25 Mar 2020 11:57:00 +0100
Message-ID: <CAOWwgp=MEA6X7NdRpid3CvpKrrYq42oBJqsC-22=xr5K40heig@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>, 
	=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ffaf3905a1abbabc"
Subject: Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000ffaf3905a1abbabc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> > https://hive.blog/php/@crell/improving-php-s-object-ergonomics


Thanks Larry, that's a good way to move forward on these topics.

I generally like the ideal of combining property declaration and
> constructors. I've had this on my mind for a while already, and also
> received the same suggestion from a couple of other people (I think Nicol=
as
> was one of them?)


I confirm: that'd be super useful to clean the boilerplate.


> large enough that I will often go with a quick and simple ad-hoc array
> structure rather than declaring an explicit value object type.


Yes


> The main concern, as others have already mentioned, is that these inline
> declarations can end up being quite verbose, especially once attributes g=
et
> involved.
>

I don't share this concern with attributes: they mix without any ambiguity,
which is what matters.
No syntax is perfect, ppl that prefer the current way will still be able to
use it.



> Named parameters are a pretty tough topic. I think one of the main points
> of contention is that they make the parameters names part of the API
> contract, and as such also subject to LSP. Your proposal offers two
> possible ways to side-step this: First, by making named parameters opt-in
> with a special syntax {}. Second, by limiting them to constructors. The
> latter variant still exposes parameter names in the API, but at least doe=
s
> not require their preservation across inheritance, as constructors are
> excluded from LSP. I'm somewhat torn on this, because it makes named
> parameters unusable with the very large body of existing methods, and
> introduces an inconsistency in which methods can use named params and whi=
ch
> don't.
>

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) [...]

My proposal is to allow any class in the casting operator: (Foo) [...]
By default, all keys of the casted array would map to properties (with an
error when no matching property exists in the current visibility scope). We
would then allow for a new constructor method, either:
public function __create(array $values)
or:
public static function __create(array $values): static

This method would take over the cast operator and decide how to construct
an instance of such a class.

There is one drawback: accepted keys are not documented. Sure, property
declarations can give a big hint.

But I think we can solve this issue later: it's not a blocker to still make
things work nicely. Also, this issue already exists with all methods that
accept an array of options - and we'll find a solution for those - either
using docblocks (there are already ways to use them for that) or using
attributes (would be the best of course, once we have them.)

Note that this __create() method looks a lot like __unserialize(): it's
just called at a different place, but the implementations could be
essentially the same.

Regarding the remainder, I think that all of readonly properties,
> asymmetric visibility and property accessors have their place and value,
> with some overlap between them. As you already mentioned, the previous
> property accessors proposal also included asymettric visibility as a
> special case, and that's how I would introduce it as well.
>

M=C3=A1t=C3=A9 suggested this syntax and it has my preference over the one =
you menton
Larry: doubling the visibility keyword could be enough to express
read+write access:

public private $property; <=3D public read access, private write access


However, I generally think that the main value really is the readonly
> properties as proposed in the recent RFC. Nowadays, a large fraction of t=
he
> classes I use are immutable value objects, for which public readonly
> properties provide a much closer match to the semantics I want.
>
> I think that the problem with with-er methods is just that: It's a proble=
m
> with with-er methods. It's what happens when you try to shove immutabilit=
y
> into something that is not actually being used in an immutable manner.
> Don't pretend things are immutable when they aren't...
>

I think "withers" solve the problem of immutability in a very pragmatic and
convenient way.

Take e.g. "private": it can be bypassed using closure rebinding or
reflection, and this is really useful, e.g. to build "friendship" relations
between classes in the same package (like in C++).

On the other side, "final" is a real pain when needing to write
proxies/decorators. It just blocks extensibility for no technical reasons
really. Let me explain: If as a consumer, I DO want to extend a class,
nothing will prevent me to do so. There is always the last resort solution,
which is patching the too restrictive source class, either using a fork or
some code rewriting tool.

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 :)

Cheers,
Nicolas

--000000000000ffaf3905a1abbabc--