Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92202
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.164 cause and error)
Reply-To: internals@lists.php.net
References: <CABdc3WqHbH6EmAZ3ZFW2spMmEmm5-yJy6rtUznNHkocVDiP8uA@mail.gmail.com>
 <CADyq6s+iTVCT8KQ13EYs4CV2W13WP+aBihsq5xHyM-hZ=jefag@mail.gmail.com>
 <CABdc3WqVGnj=WUUGJKnTfM9QVtAzshBv6ivTg2i3sA8ehdnBXw@mail.gmail.com>
 <CADyq6sJavebrYVBdYXHt6Q3imFZCDDdPu=0OQRmwJo4CLh+oww@mail.gmail.com>
 <570B2F3B.7040609@garfieldtech.com>
To: internals@lists.php.net, Larry Garfield <larry@garfieldtech.com>
Message-ID: <570BDB07.7040307@fleshgrinder.com>
Date: Mon, 11 Apr 2016 19:12:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <570B2F3B.7040609@garfieldtech.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="G8ioX1pBBnUgKFAlN2tnJNK6fdiCw6Cl5"
Subject: Re: [PHP-DEV] Final properties
From: php@fleshgrinder.com (Fleshgrinder)

--G8ioX1pBBnUgKFAlN2tnJNK6fdiCw6Cl5
Content-Type: multipart/mixed; boundary="NmQE6P2ardBRFIOT4nbMMbIBV1v3LSh8R"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net, Larry Garfield <larry@garfieldtech.com>
Message-ID: <570BDB07.7040307@fleshgrinder.com>
Subject: Re: [PHP-DEV] Final properties
References: <CABdc3WqHbH6EmAZ3ZFW2spMmEmm5-yJy6rtUznNHkocVDiP8uA@mail.gmail.com>
 <CADyq6s+iTVCT8KQ13EYs4CV2W13WP+aBihsq5xHyM-hZ=jefag@mail.gmail.com>
 <CABdc3WqVGnj=WUUGJKnTfM9QVtAzshBv6ivTg2i3sA8ehdnBXw@mail.gmail.com>
 <CADyq6sJavebrYVBdYXHt6Q3imFZCDDdPu=0OQRmwJo4CLh+oww@mail.gmail.com>
 <570B2F3B.7040609@garfieldtech.com>
In-Reply-To: <570B2F3B.7040609@garfieldtech.com>

--NmQE6P2ardBRFIOT4nbMMbIBV1v3LSh8R
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 4/11/2016 6:59 AM, Larry Garfield wrote:
> There's an important point here that should not be missed.  If these
> values are "write once then locked', which I can definitely see as
> useful, we need to have another shot at modifying them from __clone(). =

> If not, they are effectively useless for implementing objects in the
> style of DateTimeImmutable or the PSR-7 Request/Response objects.=20
> Locking after __construct or __clone (as appropriate) is done is fine,
> but if we can't clone-and-modify then I would pretty much never find
> value in this feature (no pun intended).
>=20

*__clone* support is indeed extremely important, very good point.

> I agree that final seems like a potentially confusing keyword, as every=

> other use of final (AFAIK) means "subclass cannot change this", but
> that's not at all the meaning here.
>=20

See other messages of mine in this thread.

> Another question, which unfortunately runs straight into the previous
> Properties RFC: If a public property is write-once, with the intent
> being that it's set from the constructor and then cannot be overridden
> but is publicly exposed... shouldn't an interface be able to declare it=

> as well?  It makes public properties safe to use in some cases, but you=

> can't rely on that safely without an interface.
>=20
> (Which leads to "can interfaces define properties", which leads right
> back to "well what can you do with them", which leads back to the
> Properties RFC. Which I still want to see happen at some point if at al=
l
> possible, as it would also subsume this question quite nicely.)
>=20

I do not see the relation to the RFC (not judging the actual RFC because
I liked the idea but never got into the topic to be able to judge) but I
understand the concern.

In my opinion interfaces in PHP are at the state of Java 7 interfaces
(or even a direct copy) and their functionality must be extended at some
point. Same happened in Java 8.

That being said, I agree that properties should be allowed in
interfaces, however, they must be automatically made *final* and
immutable (where I proposed the *val* keyword).

    interface Example {

        DateTimeImmutable $created;

        function example();

    }

Transforms to:

    interface Example {

        final public DateTimeImmutable val $created;

        public function example();

    }

Otherwise no consumer could rely on the interface to not change. Also
note that it does not require the RFC you mentioned because no setter,
unset, nor isset is necessary or possible if we handle it like this.

Support for mutable public properties is a different story but allowing
them would destroy the encapsulation and I am against it without anyone
bringing some good arguments that convince me.

--=20
Richard "Fleshgrinder" Fussenegger


--NmQE6P2ardBRFIOT4nbMMbIBV1v3LSh8R--

--G8ioX1pBBnUgKFAlN2tnJNK6fdiCw6Cl5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXC9sLAAoJEOKkKcqFPVVryl8P/jM3YgBBlmtzi+MhBnfRzyeL
5+nEe3DDoXsJjUOd80u73xhVbRI6h0EyS8DOmewghWNcSvvvrqG0UpK4Ht+LSmh4
bW9PoRC0OgeJhrozquJoUOstnjW4xcnZ6Hi542yzYPto4IvikhHHcoj9aea1mW6/
MIeGa+95YFf/CwZz0NlyIu0Qwf4E9VeA9zHOC2oOKykhMKe44AxqwyDYR+rXY8eA
M8PyzpShjr7xe45TVuk6c8UtV3fNj6e5WCuV2dSD0uqwzAJW8VQPeX7cHtQgBlH/
OQFN5MkhXQNciVgAH/bMhtmSLr9sR+vLDsUZ8/nacy0kXLZOVQwqMlTJvPlDtBsg
uL+1ZXA+CitJ72NqPB+HJkbxOXntOZ3Bms0lzsxYBNG2FSLcwZc1RSS0c+algzIU
UxMf3QkUn0mI3AOcksim8bjb1TTnBDflKj1Nr4YugjOffQT3GSWEiFgn26wX3FY3
aZdu/Gc5KfyPcFMnYKyb8w5DmHorSzI94Ls34KOg2DRXrh2/7V1/akC39PtN/Mq3
pYX0ZnWItnwFZyzU5ZNFwR6Sl3loNQENIJW9wE53QEuF8/yYkhkA6yevWy1ev3Ow
TAMbnfvrQpz4sqPsBBg4Jw0N5KZxo/SZ3DeutxA3K9CW9aFae6Ph7TUiT/iJuLpB
UJOuGYUv3zsvRvyFOJ4I
=qJYo
-----END PGP SIGNATURE-----

--G8ioX1pBBnUgKFAlN2tnJNK6fdiCw6Cl5--