Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.54 as permitted sender)
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: Accessors v2.2 Patch
Thread-Index: Acy4gefcaI756pCHR9ijzxam8cCDQA==
Date: Mon, 12 Dec 2011 04:01:31 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE48539955BE3@MBX202.domain.local>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_9570D903A3BECE4092E924C2985CE48539955BE3MBX202domainloc_"
MIME-Version: 1.0
Subject: Accessors v2.2 Patch
From: cpriest@zerocue.com (Clint M Priest)

--_000_9570D903A3BECE4092E924C2985CE48539955BE3MBX202domainloc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

https://bugs.php.net/patch-display.php?bug=3D49526&patch=3Dv2.2&revision=3D=
1323662103

This one addresses the read-only, write-only aspects.  Though they are not =
quite what the RFC specifies...

class TimePeriod {
   public $Hours {
      get { return 5; }
   }
}

$o =3D new TimePeriod();
$o->Hours =3D 4;

Results in:
Fatal error: Cannot set read-only property TimePeriod::$Hours, no setter de=
fined. in %s on line %d

Likewise in the other direction for write-only properties.

The difficulty is that one could extend TimePeriod and define a setter.  Th=
is is what the RFC talks about when using a readonly keyword.  There presen=
tly isn't a readonly keyword defined, nor a writeonly.

Should we create a readonly/writeonly keyword, or would something along the=
se lines be better/more flexible?

class TimePeriod {
   public $Hours {
      get { return 5; }
     private final set { }
   }
}

Creating (forcing the author to create) a private final setter which would =
not allow a set to occur and could not be over-ridden?

I've also added two tests for the read-only and write-only, as it exists in=
 the above patch.

Pierre, with the new/updated RFC, should I gut the sections that I decided =
against (such as the several alternate syntaxes) or leave them in?

-Clint



--_000_9570D903A3BECE4092E924C2985CE48539955BE3MBX202domainloc_--