Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118611
MIME-Version: 1.0
References: <CAOWwgpk7uAkZD_CH5inbm8Ng8iVL5SZsz59Mpzgpc_iG42ei8Q@mail.gmail.com>
 <CAH5C8xU=eukkqn+PToG4-JT0vqjChhkY=kd_4t_ki9mXu1UMqQ@mail.gmail.com>
 <c20b9aae-fbbf-484e-b73b-b370e4783ada@www.fastmail.com> <CAOWwgpkp0ndSgnS4aOiWqf+omcfT0_AiP0P35SC4hDZw0KDoHw@mail.gmail.com>
 <7930779c-1782-4ecd-8e3d-42ba9e199bdc@www.fastmail.com>
In-Reply-To: <7930779c-1782-4ecd-8e3d-42ba9e199bdc@www.fastmail.com>
Date: Mon, 12 Sep 2022 21:58:32 +0200
Message-ID: <CAOWwgpmbjbGm2NYe99=qzdtZkPVY=aYe-bJFtfZC-G7nxZyd+A@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>, =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bafc4a05e88052f5"
Subject: Re: [PHP-DEV] Re: Issues with readonly classes
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000bafc4a05e88052f5
Content-Type: text/plain; charset="UTF-8"

> >> Personally I'm undecided at the moment whether or not it should be
> >> allowed.  I'm sympathetic to the "it's easier to disallow and allow
> later
> >> than vice versa" argument, but still not sure where I stand.  The above
> at
> >> least gives a concrete example of where the problem would be.
> >>
> >
> > If we want the safety you describe, we might want a stronger version of
> it.
> > Let's name it immutable. An immutable property/class would be like a
> > readonly property with the additional restriction that only an immutable
> > value could be assigned to it (scalars + array + immutable classes.) But
> > that's another topic.
> >
> > Your example made me doubt for a moment, but without any convincing
> > purpose, this should help decide that child classes shouldn't have to be
> > readonly.
> >
> > Nicolas
>
> Another question I think is pertinent to ask: What kinds of objects
> generally would be proxied in this way, and are those the kinds of objects
> where a readonly object would make sense?
>
> Off hand, I'd expect this kind of proxying to be used mainly on services,
> whereas readonly classes would be mostly value objects.  So the problem
> space may be smaller than it initially appears.
>

It's very difficult to anticipate this. Here is a counter argument:
About services: the best ones are of the functional sort; they don't hold
any states and their dependencies are also pure functional units. Aka
they're immutable and they're good candidates for readonly classes.
About entities: e.g. Doctrine proxies them all.
So no, I wouldn't say that services are the most common things to proxy,
and that entities are the most common things to use readonly on...

I hope this discussion illustrated why we should remove propagating
readonly to child classes: it serves no purpose and it breaks a universal
design pattern. There is no rationale that supports the current behavior.

Mate, WDYT?

Cheers,

Nicolas

--000000000000bafc4a05e88052f5--