Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99670
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJW__o3PtvPzQo+yk=3sm8mE-ytZUJ-Cbo8iXgK4zs3Uyhb_KA@mail.gmail.com>
References: <CAEsg9X0sJ=JYxHfAs6a2Pp4Oymtkqi+JcDfX2+u4MP_pZTK9NA@mail.gmail.com>
 <CAJW__o3ynh3C=CBxD4LaLyE9DsLPhBExyvCgtabvn4cYuz4Vxg@mail.gmail.com>
 <CAEsg9X3EbgYiMdA8eUV1usKBTfJSbiJFG7E7mU4-hBRaAP+uyg@mail.gmail.com>
 <CAEsg9X1cxQY+TBM2Q0zsdvc0QcfrJMxgfefNtdoFstWxfrrJYg@mail.gmail.com> <CAJW__o3PtvPzQo+yk=3sm8mE-ytZUJ-Cbo8iXgK4zs3Uyhb_KA@mail.gmail.com>
Date: Thu, 29 Jun 2017 06:20:39 +0200
Message-ID: <CADyq6sKyuDisCVVhwopL3V2VaUu5rs97V6n8esyD8LYHZBVTiQ@mail.gmail.com>
To: Kalle Sommer Nielsen <kalle@php.net>
Cc: David Rodrigues <david.proweb@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045d599ca60ef40553119f5d"
Subject: Re: [PHP-DEV] Final variables
From: ocramius@gmail.com (Marco Pivetta)

--f403045d599ca60ef40553119f5d
Content-Type: text/plain; charset="UTF-8"

The `final` modifier would likely clash with property type definitions, if
those ever make it to the language.

Still, a few pain-points remain:

 * References to properties (you cannot reference final properties anymore,
and that is effectively a BC break for anything using reflection and
closure scope binding)
 * Arrays and resources as properties
 * Named (Factory) constructors
 * Property nullability - how do you define if a property was written to
the "last valid time" before freezing it
 * Unset properties and providing an alternative mechanism to distinguish
"uninitiated",  "undefined" and "frozen" in he event of final properties
usage, without breaking current property access semantics

This is the exact same set of problems we had with the typed properties
RFC, and which caused the RFC to fail: please take all these in
consideration while designing the feature.

On 29 Jun 2017 4:57 AM, "Kalle Sommer Nielsen" <kalle@php.net> wrote:

> 2017-06-29 1:07 GMT+02:00 David Rodrigues <david.proweb@gmail.com>:
> >   readonly $number = mt_rand();
> > I agree that "readonly" is a better keyword, but we have to points here:
> > 1. "final" is used on some language (Java, C++ I guess);
> > 2. "final" keyword does exists on PHP with a "similar" behaviour;
>
> > If we can implements "readonly" is good too, because turn it more
> implicit.
> True we could re-use the final keyword, but think about it this way,
> we got final methods and final classes which means it cannot be
> overridden/extended respectively, if the final keyword then would also
> apply to variables but it would mean they could not be written to,
> that would create a WTF-factor.
>
> The readonly keyword would work for any visibility modifiers, so
> inherited classes or extending classes may read a protected property,
> but not modify it as well:
>
> class A {
>  protected readonly $b;
>
>  public function __construct() {
>   $this->b = 'C';
>  }
> }
>
> class B extends A {
>  public function read() {
>   echo $this->b;
>  }
>
>  public function write() {
>   $this->b = 'D';
>  }
> }
>
> $b = new B;
>
> $b->read(); // "C"
> $b->write(); // <- error
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> kalle@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f403045d599ca60ef40553119f5d--