Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91694
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
Date: Wed, 16 Mar 2016 10:08:53 -0700
Message-ID: <CADajX4Cpk-jXtmp3pTFFPu737vMQ5YGGdT5eqBGxFC6D0zp=Yw@mail.gmail.com>
To: Phil Sturgeon <pjsturgeon@gmail.com>
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: aharvey@php.net (Adam Harvey)

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!

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