Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61298
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-BO8Sii6uXmdbixNUh=OuSF_hAAi3ZUqvjnkvjbmdu8Q@mail.gmail.com>
References: <CAH-PCH738OneYAv-6jNvN5qXN0SzGyOMfxCd=vZ-qAykL_WZ6A@mail.gmail.com>
 <CAF+90c-BO8Sii6uXmdbixNUh=OuSF_hAAi3ZUqvjnkvjbmdu8Q@mail.gmail.com>
Date: Mon, 16 Jul 2012 14:44:06 +0100
Message-ID: <CAN+gjScyk23PT-HqTe__4DUxUBMc3Dh5bUkbK_hkLp65ecYzXg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] supporting the final keyword for properties
From: ajfweb@googlemail.com (Andrew Faulds)

In that case, we should use what C# calls it, "readonly". Writable
only once by the constructor.

On 16 July 2012 14:35, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>> Hi,
>>
>> The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html
>> discussion
>> made me wonder why did we decide not supporting the final keywords for
>> properties as it would provide an easy way for read-only attributes (const
>> would be a better choice in performance wise, but then you can only set it
>> in your declaration where no dynamic expression is allowed.)
>>
>> I would like it to work the same way as it does in java(
>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) eg.
>> you can set the initial value either in the declaration or later on, but
>> after it is set, you can't change it, trying to do that would create a
>> recoverable fatal error (or throwing an exception which extends
>> RuntimeException).
>>
>> What do you think? Would this be viable? Is there any still-present reason
>> why we shouldn't support that?
>
> I don't like this overloaded meaning of "final". "final" currently
> means "cannot be overwritten by inheritance". This would add a second
> meaning which would be somewhat similar to "const" (but only
> somewhat).
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Andrew Faulds (AJF)
http://ajf.me/