Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91748
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com>
Date: Fri, 18 Mar 2016 12:48:33 +0100
Message-ID: <CADyq6sJxUrTQu__mQv-649cyvg4htzG+VK5g400b5-Vrvs5+TQ@mail.gmail.com>
To: Phil Sturgeon <pjsturgeon@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113c9ba0d1c2ce052e5154c2
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: ocramius@gmail.com (Marco Pivetta)

--001a113c9ba0d1c2ce052e5154c2
Content-Type: text/plain; charset=UTF-8

To answer my own question: the entire RFC is a no-go in its current state.
On 18 March 2016 at 10:09, Marco Pivetta <ocramius@gmail.com> wrote:

> That said, I have a few quite common use-cases that arise and that are a
> bit problematic, both because they are hacks and because they are actually
> used in large projects.
>
> Specifically, I'm worried about two particular use-cases:
>
>  * unsetting properties
>  * by-ref property assignment
>
> To clarify, un-setting properties allows us to hide properties completely,
> loading them on a per-usage basis:
>
> class Foo {
>     public int $bar;
>     public function __construct() {
>         unset($this->bar); // is this operation legal? For BC compliance,
> I'd expect that to be the case
>     }
>     public function __get(string $name)
>     {
>         initialize_properties_here($this); // external thing connecting to
> db, loading files, yadda yadda
>     }
> }
>
> var_dump((new Foo())->bar); // what happens here? can
> `initialize_properties_here` actually assign a non-int to `$bar`? Will the
> type safety still work?
>

See https://3v4l.org/bsHXH/rfc#tabs - unset() doesn't work, and that breaks
some basic PHP semantics that are covered by phpt tests, but just for the
case of typed properties.


> The by-ref property assignment is a bit trickier, but can probably be
> worked around with some overhead (re-assigning).
> Here's what is going on:
>
> class Foo {
>     public int $bar;
>     public function __construct() {
>         unset($this->bar);
>     }
>     public function __get(string $name)
>     {
>         $this->bar = 123; // default value
>         $props = ['bar' => & $this->bar]; // is this operation now
> considered illegal?
>         initialize_properties_here($props); // external thing connecting
> to db, loading files, yadda yadda
>     }
> }
>


See https://3v4l.org/sKqYb/rfc#tabs - by-ref assignment is forcefully
disabled, and that breaks some more PHP semantics just for the case of
typed properties.

To sum it up, the RFC has one major problem: it focuses on the WHEN
assignments happen, rather than just checking WHAT is assigned.

I think the scope of the proposal needs to be reduced strictly to type
checking.
As it stands, this is too magic (and I do qu

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--001a113c9ba0d1c2ce052e5154c2--