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?
-----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 2820I second getting rid of write-onle - the only real case I can think of, is 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 accessor.As for read-only, I strongly advice against overloading the const keyword with an entirely new meaning, if that's what you're
suggesting?Just drop the idea of read-only altogether, please - it's so marginally useful in the first place, unconventional compared to other
languages, and will just get in the way. For most properties that only have 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.---------- 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 / write-only keywords"no equivalent replacement has been suggested" => ouch
read-only => const
write-only => shouldn't exists. A write-only accessor is just a method disguised in property.
It's not a good idea to allow:
$obj->prop = 3;
when the meaning is:
$obj->meth(3);
Clint Priest wrote:
Hey Rasmus, please try and keep these replies in the appropriate thread...
And bottom post please ...
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.
But the question still remains. Isn't a read only variable simply a 'const'? Why
do we need anything more than that? It explains exactly why it has been defined
without any ambiguity and works everywhere.
write-only is a more 'specialist' concept as you need information back to
confirm that it has been set, or if there was an error. Simply writing a value
blind makes no sense?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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.But the question still remains. Isn't a read only variable simply a
'const'? Why do we need anything more than that? It explains exactly why it
has been defined without any ambiguity and works everywhere.
A read-only variable may be calculated from other values, and there may not
be an inverse calculation. As a concrete example, consider an invoice total
calculated from line items. It will change as the line items change, but it
wouldn't make sense to me to be able to set the order total and have that
somehow be back-propagated to the line items.