Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91744
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
Date: Fri, 18 Mar 2016 10:09:17 +0100
Message-ID: <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com>
To: Phil Sturgeon <pjsturgeon@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f17d63aa32b052e4f1bb6
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: ocramius@gmail.com (Marco Pivetta)

--001a113f17d63aa32b052e4f1bb6
Content-Type: text/plain; charset=UTF-8

Hi Phil,

On 16 March 2016 at 17:36, Phil Sturgeon <pjsturgeon@gmail.com> wrote:

> Hello everyone,
>
> I have completed the draft for an RFC, to add Typed Properties. The
> patch has been written by the one and only Joe Watkins.
>
> https://wiki.php.net/rfc/typed-properties
>
> I would really appreciate constructive feedback on this RFC, with a
> few areas especially:
>
> 1. How scared are we that integers can be expanded to floats on runtime?
>
> 2. This whole temporary nullability situation, where unset properties
> will error on attempted usage if not set. Should they instead error
> after the constructor has been called if they are still not holding a
> value?
>
> 3. Weak vs Strict. Right now this is entirely strict, with no
> declare() to change mode. Reasons for this vary, from various sources,
> but include "Not sure how to implement it" and "Well people should not
> be using properties as part of their public API".
>
> Help on 3 would be appreciated.
>
> Also let's please avoid "PHP IS TURNING INTO JAVA" and the other
> rather common rhetoric. Strict Type Hinting might have been seen as a
> battleground for fans of strict and fans of weak to fight through a
> keyboard, but this RFC will not be the repeat.
>
> We'll have a nice, orderly, constructive conversation about this RFC,
> and improve the patch as you all provide feedback.
>
> Let me know what you think folks!
>


I really love the RFC, thanks for working with Joe on this.

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?

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
    }
}

In addition to these questions, I think that the reflection API also needs
a `ReflectionProperty#getType() : ReflectionType` addition in order for the
RFC to be complete.

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--001a113f17d63aa32b052e4f1bb6--