Hi!
> 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
Why is it ambiguous? It's pretty well defined, it's the same as public.
> class Foo {
>
> val $x;
>
> var $y;
>
> val $z;
>
> }
>
> class Bar extends Foo {
>
> var $x;
>
> $y;
>
> $z;
>
> }
This looks very unobvious what is supposed to be going on here. I'd
much prefer to have every specification be explicit.
> The /z/ will stay a *val* (immutable) because its parent
> declaration is defined as such.
>
> class Point {
>
> final public float val $x = 0.0;
Wait, how is this different from a constant?
> 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*.
I'm not sure I understand what is the point in freezing the
definition. Could you explain use case for such thing?
> 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.
I'm not sure why var is unusable and why it is a worthy goal to make
it "usable again" - i.e. what exactly we are trying to achieve here?
If we want value objects, it *might* be valuable to have an object
that is readable but not writable from outside - even though it is
easily achievable right now by having public getters but no public
setters. But I'm not sure how "var" - or, for that matter, "final" -
fits the picture.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
