Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63572
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
Sender: Maciek Sokolewicz <tularis@gmail.com>
Message-ID: <50830276.7030307@php.net>
Date: Sat, 20 Oct 2012 21:58:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Clint Priest <cpriest@zerocue.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <9570D903A3BECE4092E924C2985CE485612C2595@MBX214.domain.local>
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612C2595@MBX214.domain.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
From: maciek.sokolewicz@gmail.com (Maciek Sokolewicz)

On 20-10-2012 19:20, Clint Priest wrote:> 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 
implementing no "special code" to make what was read-only/write-only 
language enforced.  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"); }
 > 	}
 > }
 >
 > This solution introduces no magic on the engine side and lets those 
who need a read-only / write-only type scenario to "work."
 >
 > Does this sound like an effective solution for everyone?
 >

Ok, time to put it in the correct thread again, with actual working 
threading.

For the last few days I've been wondering why the hell anyone would 
really need a write-only keyword; and the only answer to this that I 
could think of was that "it would be nice" since you could catch such 
problems automatically, instead of actually having to write additional 
custom code which prevents access to the set-accessor. Apart from that, 
there is also the thing that using this additional keyword you can (if 
implemented at all) show that such a method does NOT exist in interfaces 
/ reflection.

Anyway, the 'solution' of not adding a lot of confusing keywords to say 
something that can be said simply using code inside the function... 
seems very good to me. I must admit I'm surprised noone has brought it 
up till yesterday.

- Tul (casual internals reader)