Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108713
MIME-Version: 1.0
References: <CAH5C8xVYFkgyW88332ei8coMOijuynHXg3A2dL50XU4HP5Vpyw@mail.gmail.com>
 <CAKuGYLTsK2h_Yeo1vMju867hhmzyHt+GwoGStcQtiYMi2VB1tg@mail.gmail.com>
 <CAF+90c9RKf5PUQY0XHf=8QVVMw8jiJ=7eWfY5TTANEYt-a-ZAA@mail.gmail.com> <8545d15e-ddd5-42be-8405-09697a077234@www.fastmail.com>
In-Reply-To: <8545d15e-ddd5-42be-8405-09697a077234@www.fastmail.com>
Date: Fri, 21 Feb 2020 11:29:52 +0100
Message-ID: <CAH5C8xWgkUCAJguwnP69VqWXUaR+QtJRPMyBdv7B5vcnQjTD1g@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000216aa7059f1381cf"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000216aa7059f1381cf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> Yeah, I'm definitely thinking in relation to the earlier discussion, sinc=
e
> I think they're all inter-related.  (This, property accessors, and consta=
nt
> expressions.)
>

The biggest question is whether it's worth to support both readonly
properties and property accessors. My answer is clear yes, because there
are many-many
ways to mess with private or protected properties without and public
setters from the outside - in which case property accessors couldn't help
much. I collected some examples I know of:
https://3v4l.org/Ta4PM

Please note that the first two examples also apply to private properties,
while the last one only applies to protected ones.


> As Nikita notes above, a read-only property with a default value is...
> basically a constant already.  So that's not really useful.
>

I agree that they are not very useful, however I wouldn't restrict their
usage. Mainly because there are probably some legitimate use-cases, but I
also think it would
be advantageous to be consistent with the other languages in this case.


> For defined-later readonly properties, I'm not sure how the earlier point
> about reading an unintialized property isn't valid.  Currently:
>
> class Foo {
>   public string $bar;
> }
>
> $f =3D new Foo();
> print $f->bar; // this throws a TypeError.
>
> I would expect the exact same behavior if $bar were marked
> readonly/locked/whatever.  Are you saying that's not the case?
>

Sorry if I didn't exactly get the question/example, but what I can tell you
is that currently an Error exception is thrown with the
"Typed property Foo::$bar must not be accessed before initialization"
message, and it would be the case with my patch as well
since it doesn't affect the reading side.

The situation is the same when it comes to unsetting uninitialized typed
properties. Currently, these properties can be unset with no problem (and
the
__get(), __set() etc. magic methods are then invoked when accessing them),
and the same would happen with my patch.


> If we could address the performance impact, that would give us much more
> functionality-for-the-buck, including an equivalent of read-only properti=
es
> including potentially lazy initialization.  Or derive-on-demand behavior
> would also be a big increase in functionality.
>
> It's not that I don't see a value to this RFC; I actually have a few
> places in my own code where I could use it.  It's that I see it as being =
of
> fairly narrow use, so I'm trying to figure out how to increase it so that
> the net-win is worth it.
>

The reason why I brought up this RFC is that I'd really like to add
first-class support for immutable objects, and it seemed to be a good idea
to first go for readonly properties.
This way, the scope of an immutable object RFC gets smaller, while it's
possible to only have readonly properties alone.

Regards,
M=C3=A1t=C3=A9

--000000000000216aa7059f1381cf--