Re: Final properties
| From: | Fleshgrinder | Date: | Mon, 11 Apr 2016 16:50:46 +0000 |
| Subject: | Re: Final properties | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-92200@lists.php.net to get a copy of this message | ||
/Sending this again because the PHP mail server was down./
I thought some more about it and I think that the best choices would be
*val* (for /value/) and *var* (for /variable/) as in Scala.
Why?
The *var* keyword is not going to be deprecated and its meaning is
currently kind of ambiguous. I tried to assign it a new meaning in the
thread about /Access and Visibility Modifiers/ thread
(http://marc.info/?l=php-internals&m=146005798902985&w=2) but as Rowan
Collins pointed out, it would be kind of weird to continue using *var*
for anything related to access/visibility because it simply means
something else; it means /variable/.
The introduction of a counterpart to it would allow it to finally have a
meaningful functionality and it would not introduce any kind of BC for
old code.
class Foo {
val $x;
var $y;
val $z;
}
class Bar extends Foo {
var $x;
$y;
$z;
}
The parent defines its property as being a *val* (immutable) and the
extending class lifts this constraint by redeclaring it as a *var*
(mutable). Doing so ensures that the developer must know what she is
doing and hence makes the language overall more secure.
There is no BC for the /y/ property because the parent is already
mutable and implicit public (or hopefully /assembly visible/ in the
future, see other references thread), hence, the /y/ in the child class
simply stays mutable.
The /z/ will stay a *val* (immutable) because its parent declaration is
defined as such.
class Point {
final public float val $x = 0.0;
final public float val $y = 0.0;
}
final class Point3d extends Point {
final public float val $z = 0.0;
}
final class MutablePoint extends Point {
final public float var $x; // FATAL ERROR
final public float var $y; // FATAL ERROR
}
The *final* keyword could be added via another RFC and it would have the
same meaning as the *final* keyword for classes and methods: freeze the
definition. This is why the *MutablePoint* results in fatal errors: it
tries to redeclare /x/ and /y/ from *val* to *var* although they are
*final*.
Note that this could be easily extended to local variables at a later
stage as well and it would be extremely useful.
I think that Scala's *val*/*var* approach could really help us to make
*var* usable again in a meaningful manner and it corresponds nicely to
the concept of /value objects/ and related concepts with its naming scheme.
What do you think?
--
Richard "Fleshgrinder" Fussenegger
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc