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)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
