/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
signature.asc
Description: OpenPGP digital signature
