Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63568
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.80 as permitted sender)
To: Rasmus Schultz <rasmus@mindplay.dk>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
Thread-Index: Ac2u5eZBmV2f+qcsSKiHvFm0bIOrBA==
Date: Sat, 20 Oct 2012 17:20:50 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE4856140BA80@MBX202.domain.local>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
From: cpriest@zerocue.com (Clint Priest)

Hey Rasmus, please try and keep these replies in the appropriate thread...

I am in favor of eliminating the read-only/write-only keywords and implemen=
ting no "special code" to make what was read-only/write-only language enfor=
ced.  I think the alternatives with final are just fine and good enough and=
 will let userland programming enforce it if they so desire.

Example of user-land enforced 'read-only' code:

class A {
	public $b {
		get() { ... }
		private final set($x) { throw new Exception("cannot set $b"); }
	}
}=20

This solution introduces no magic on the engine side and lets those who nee=
d a read-only / write-only type scenario to "work."

Does this sound like an effective solution for everyone?=20

> -----Original Message-----
> From: Rasmus Schultz [mailto:rasmus@mindplay.dk]
> Sent: Saturday, October 20, 2012 9:45 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Re: internals Digest 20 Oct 2012 09:49:39 -0000 Issue =
2820
>=20
> I second getting rid of write-onle - the only real case I can think of, i=
s something like a password property on a user/account model-
> type, which gets encrypted and thus can't be read, and as Amaury pointed =
out, that should be a setPassword() method instead,
> perhaps even a separate UserPasswordService component. Certainly not an a=
ccessor.
>=20
> As for read-only, I strongly advice against overloading the const keyword=
 with an entirely new meaning, if that's what you're
> suggesting?
>=20
> Just drop the idea of read-only altogether, please - it's so marginally u=
seful in the first place, unconventional compared to other
> languages, and will just get in the way. For most properties that only ha=
ve a read-accessor, it won't even make any sense for someone
> to try to extend that with a write-accessor. And as said, if you want to =
keep the internal value safe from write, just declare the actual
> property as private.
>=20
> ---------- Forwarded message ----------
> From: Amaury Bouchard <amaury@amaury.net>
> To: Clint Priest <cpriest@zerocue.com>
> Cc: "internals@lists.php.net" <internals@lists.php.net>
> Date: Sat, 20 Oct 2012 10:09:35 +0200
> Subject: Re: [PHP-DEV] [RFC] Accessors v1.1 -> v1.2 Summary read-only / w=
rite-only keywords
>=20
> "no equivalent replacement has been suggested" =3D> ouch
>=20
> read-only =3D> const
>=20
> write-only =3D> shouldn't exists. A write-only accessor is just a method =
disguised in property.
>=20
> It's not a good idea to allow:
>     $obj->prop =3D 3;
> when the meaning is:
>     $obj->meth(3);