Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91697
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4Cpk-jXtmp3pTFFPu737vMQ5YGGdT5eqBGxFC6D0zp=Yw@mail.gmail.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
	<CADajX4Cpk-jXtmp3pTFFPu737vMQ5YGGdT5eqBGxFC6D0zp=Yw@mail.gmail.com>
Date: Wed, 16 Mar 2016 13:26:33 -0400
Message-ID: <CABDNdAESqQpt7S8YaBF2bsXCcBM9sz-jGgBpUzGY2e_QF60cCg@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: pjsturgeon@gmail.com (Phil Sturgeon)

On Wed, Mar 16, 2016 at 1:08 PM, Adam Harvey <aharvey@php.net> wrote:
> On 16 March 2016 at 09:36, Phil Sturgeon <pjsturgeon@gmail.com> wrote:
>> 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".
>
> As much as I didn't (and don't) particularly like the declare()
> switch, it doesn't seem like a good idea to me to introduce a typing
> feature a year after it that doesn't use it, but has its own mode of
> operation. To me, it seems like this:
>
> class Foo {
>   public int $num;
> }
>
> (new Foo)->num = $bar;
>
> Should behave the same as the setter equivalent does today:
>
> class Foo {
>   public $num;
>   public function setNum(int $num) { $this->num = $num; }
> }
>
> (new Foo)->setNum($num);
>
> That is: if $num either can't be coerced to an integer (in weak mode)
> or isn't itself an integer (in strict mode), a TypeError should be
> thrown.
>
> We could argue about whether properties should be part of a public
> API, but the reality is that a class declaring a public property
> effectively is making it part of its API, whether you or I think it's
> a good idea or not. :)
>
>> 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!
>
> The above leads into another question I'm interested in your (and
> Joe's) general thoughts on: how do you think this would potentially
> intersect with a property getter/setter RFC in the future? Might be
> good fodder for the future scope section!

Yeah, I'll add a note about that. :)

> Finally, while the RFC shows invalid assignments generating fatal
> errors, the patch seems like it throws TypeError exceptions instead.
> Which one is the desired behaviour? (I'd prefer TypeError, personally,
> for consistency with function type declarations today.)
>
> Adam

If you put them in the class definition you'll get a fatal error from
the compiler (might change) and at runtime you get an Error. Different
things for different things. :)