Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61294
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nHE7RkVV4j5=LiQgVqnTrHQ74CuwLhf6MNWpuuVO+YS8Q@mail.gmail.com>
References: <CAH-PCH738OneYAv-6jNvN5qXN0SzGyOMfxCd=vZ-qAykL_WZ6A@mail.gmail.com>
	<CAAyV7nHE7RkVV4j5=LiQgVqnTrHQ74CuwLhf6MNWpuuVO+YS8Q@mail.gmail.com>
Date: Mon, 16 Jul 2012 15:25:53 +0200
Message-ID: <CAH-PCH4PLOs7C_DrPuPvkZeK0Lk1WZf8gdE+YVvSeap+YdB3RQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b33d0887d91ba04c4f25e24
Subject: Re: [PHP-DEV] supporting the final keyword for properties
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b33d0887d91ba04c4f25e24
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 16, 2012 at 2:59 PM, Anthony Ferrara <ircmaxell@gmail.com>wrote=
:

> Ferenc,
>
> On Mon, Jul 16, 2012 at 8:25 AM, 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 (con=
st
>> 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 reas=
on
>> why we shouldn't support that?
>>
>
> My question would be where in code would this be enforced? A trivial
> implementation could be done in the object.write_property handler. But
> wouldn't things like references and the such (read_property and
> get_property_ptr_ptr, as well as get_properties) also be paths to
> writability?
>
> Would that then mean that this would need to be added to the zval type
> directly, and not just the property table? And if that's the case, why no=
t
> make it final for the entire engine (meaning that I can declare a global
> property as final using `final $var =3D 1;`)... Thereby making this a rat=
her
> significant engine changes? Or is there an easier way that I'm missing...=
?
>
> Anthony
>

Introducting final for the procedural code would be a bad idea imo, but on
the other hand it would be in sync with the fact that we added the const
keyword to be used in the global scope for example.
About whether we should handle it in the zval or in the
object.write_property I also don't have a strong opinion, I see both cons
and pros.

Another thing: If implemented, we should add a few methods to Reflection
like:

   - ReflectionProperty::isFinal(void)
   - ReflectionProperty::setFinal(bool $final)

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b33d0887d91ba04c4f25e24--