Re: Final properties

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 smalyshev@gmail.com