Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115226
MIME-Version: 1.0
Date: Wed, 30 Jun 2021 10:36:15 +0200
Message-ID: <CAHRtwKZBy5SWBoGHNNwnd89jgh1oBaN5GtrRzQveh7=dKsUMfA@mail.gmail.com>
To: larry@garfieldtech.com, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: [RFC] Readonly properties
From: andre.romcke@gmail.com (=?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?=)

> > It's okay to vote against this if cloning is a deal breaker. In that case
> > I'll probably either work on cloning before re-proposing this, or pivot to
> > asymmetric visibility -- it's not my first preference, but it may be the
> > more pragmatic choice. Cloning is definitely the weak point of this
> > proposal.
>
> I already went through the clone-arguments mental exercise in my earlier analysis, and the code
> it produces is totally disgusting. :-)  clone-with is a considerably better approach if you're starting
> from readonly.  (It's also better if you start from asymmetric visibility, although that version needs
> a clone-help feature far less.)


Internals have been here before, it's a recurring problem in PHP that
fundamentally missing features are voted down because people want
other complementary features first.

read only has been voted down by people rather wanting type properties
first, or rather wanted assessors first. And then in turn accessors
multiple times were voted down by the other 2 camps. But these
features are interconnected and need to be done step by step, during
the process things won't be perfect either way,

Now we have read only vs clone with vs accessors vs ...

IMO problem caused by no clear roadmap / vision of the project that
people can be united behind.

--

Anyway, even though I tried to push for asymmetric visibility last
year I'd gladly vote +1 on this.
It's not perfect, but it's the right direction, and there are multiple
starting points to get there.

This solves 80-90% of the use cases out there for read only
properties, which is a very good start.

--

Nikita: Probably a small thing, but the only detail I'm unsure of is
why focus on write-once logic? Why not aim for aligning it with a
future *:init visibility, where I would think the property in PHP
should be writable in __construct(), __destruct() and __clone().

This won't solve the separate clone with feature request. But it would
make it more flexible and language design wise would set it up for
possible asymmetric visibility + init option later.

For now it would at least allow setting default values on the
property, for instance if argument to constructor is not 1 to 1 with
property type/value and needs some light logic in __construct to
determine if property should be set to something else then default.

But again, don't see a blocker here in current RFC, as it starts out
with a narrow scope of read only, and this can be widened later.