Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108592
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-ID: <60cc7417-837d-4ca2-8661-e32b255ef2db@www.fastmail.com>
In-Reply-To: 
 <CAH5C8xWFBJ32XvnQGfwwuCw4-E2oFXgizSxzYuF0jk5Bt_xHWQ@mail.gmail.com>
References: 
 <CAH5C8xWFBJ32XvnQGfwwuCw4-E2oFXgizSxzYuF0jk5Bt_xHWQ@mail.gmail.com>
Date: Sat, 15 Feb 2020 02:18:15 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Feb 14, 2020, at 7:22 AM, M=C3=A1t=C3=A9 Kocsis wrote:
> Hi Internals,
>=20
> I'd like to propose the idea of adding support for immutable/final/rea=
donly
> properties in PHP 8.
>=20
> My plan is to add a new immutable/final/readonly (the name is up for
> debate) property modifier to the language so that these kind of proper=
ties
> could only be initialized but not modified afterwards. Unlike how fina=
l
> properties in Java work, I think it would be beneficial to allow lazy
> initialization of these properties after object construction have take=
n
> place. Currently, I'm in favour of using final or readonly, but not ye=
t
> very sure.
>=20
> I'll write a proper RFC in the following days/week. My clear intent wi=
th
> final properties is to pave the road for immutable objects for which I=
 have
> a POC pull request open (but I haven't pushed all my work yet).
>=20
> So far, my biggest question (apart from the name) have been how non-ty=
ped
> properties should behave: as they are implicitly initialized to null i=
f
> they don't have an explicit default value (while typed properties rema=
in
> uninitialized), further modifications would be impossible to do on the=
m -
> which would make non-typed final properties almost useless. Nikita
> suggested to just avoid their initialization, but I'd be curious about=

> other ideas as well.
>=20
> Thanks,
> M=C3=A1t=C3=A9 Kocsis

My concern is that a simple read-only/final "flag" is a very limited fea=
ture set.  I'd still love for us to revisit property accessors at some p=
oint (if the performance issues could be resolved), and I fear that laye=
ring that *and* a read-only flag together would result in... much comple=
x weirdness.  (Technical term.)

That said, were such a feature to be added, I would strongly recommend m=
aking them able to be defined in terms of an expression, or possibly a c=
allable/anon function, with no explicit setting allowed.  To wit:

class Foo {

  protected string $firstName;
  protected string $lastName;

  protected function getFullName() { return $this->firstName . $this->la=
stName; }

  // And then one of these options:

  public final string $fullName =3D $this->firstName . $this->lastName;

  public final string $fullName =3D fn() =3D> $this->firstName . $this->=
lastName;

  public final string $fullName =3D $this->getFullName();
}

That would allow for their complete definition in one location, make it =
clear how they're derived, etc.  They essentially become an auto-memoizi=
ng method (which suits me just fine).  Their value would potentially cha=
nge depending on when it's first called depending on the other values in=
 the object, but that's no different than if they were simply "set" from=
 an arbitrary location.  The potential for unpredictable semi-non-determ=
inism is the same, or possibly better this way.

(In that case, "final" or "lazy" or "locked" would be reasonable names; =
read-only and immutable are misleading, as it's really write-once, not r=
ead-only, not truly immutable.  I suppose then an "immutable object" wou=
ld be one in which all properties are either final/lazy/locked or set by=
 the constructor only.)

There was a thread a few weeks ago on "lazily derived constants" that pr=
obably has some interesting thoughts as well, though of course this woul=
d be property-like syntax, which is fine.

As for references and untyped final properties...  Just don't go there. =
 Require a final property to be non-reference and typed.  I do not fores=
ee untyped properties ever going away (too much legacy code, plus they a=
re legit useful at times), but that doesn't mean every conceivable prope=
rty variant ever needs to support them.  Requiring that a final property=
 be typed non-reference seems entirely reasonable to me.

--Larry Garfield