Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92244
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.174 as permitted sender)
To: internals@lists.php.net
References: <CABdc3WqHbH6EmAZ3ZFW2spMmEmm5-yJy6rtUznNHkocVDiP8uA@mail.gmail.com>
 <CADyq6s+iTVCT8KQ13EYs4CV2W13WP+aBihsq5xHyM-hZ=jefag@mail.gmail.com>
 <5708B197.9020108@php.net> <9C0BBB93-8173-45CF-9636-888B340828FD@ez.no>
 <CANUQDCgQvs6OpJGUyDd-Nigjg9mG-mAyqgLAjgr8a-7abG3HFQ@mail.gmail.com>
 <57090928.3040905@php.net>
 <CANUQDChuJvVeZruyRSCqBwUtNqiuGX=COrfz17srvh6pDYnVdA@mail.gmail.com>
 <570BD5E6.2000304@fleshgrinder.com>
Message-ID: <570DCE46.3020800@gmail.com>
Date: Tue, 12 Apr 2016 21:42:46 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <570BD5E6.2000304@fleshgrinder.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Final properties
From: smalyshev@gmail.com (Stanislav Malyshev)

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