Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91698
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP1233D64DB1FE198EA1FC04BE28A0@phx.gbl>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
	<BLU436-SMTP1233D64DB1FE198EA1FC04BE28A0@phx.gbl>
Date: Wed, 16 Mar 2016 17:27:55 +0000
Message-ID: <CABHuAWw2vf+haXBhgu505RXZ=EK-5W_7Y6GcOrqcjWeNyKT51g@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Phil Sturgeon <pjsturgeon@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11410bb69352de052e2dd508
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: t.carnage@gmail.com (Chris Riley)

--001a11410bb69352de052e2dd508
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 16 March 2016 at 17:17, Bob Weinand <bobwei9@hotmail.com> wrote:

> Hey, thank you both for investing your time :-)
> Property types are definitely interesting.
>
> > Am 16.03.2016 um 17:36 schrieb Phil Sturgeon <pjsturgeon@gmail.com>:
> >
> > 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=
?
>
> This IMHO is quite necessary, for the same reasons why we even allow int
> to float widening with strict return types.
>
> class foo {
>     float $bar;
>     function __construct(int $x) {
>         assert($x > 0);
>         $this->bar =3D 10 / $x;
>     }
> }
>
> This is perfectly innocuous, but will fail for values 1, 2, 5 and 10, if
> we don't allow widening.
> Depending on the values it might also be not caught in testing.
>
> > 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?
>
> Erroring when using the unset property is the way to go.
>
> The example from the RFC is showing exactly why...
>
> class Foo {
>     public int $foo;
> }
> $foo =3D new Foo();
> echo $foo->foo; // Patch currently errors here
>
> With one property, not so much an issue, we could force a constructor.
> But with 20 properties, definitely an issue.
>
> If we'd error after constructor call, there are also other complications=
=E2=80=A6
>
> class Foo {
>     public int $bar;
>     function __construct() {
>         global $foo;
>         $foo =3D $this;
>     }
> }
> try {
>     new Foo;
> } catch (Error $e) {}
> var_dump($foo->bar); // not set, but instance is referenced
>
> Sure, we could find ways to circumvent that and change the class to
> totally non-functional and making every usage of it throw an Error, but i=
t
> isn't quite elegant.
>
> > 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.
>
> Now, if we already have int to float widening (which I recommend), we
> anyway need to do certain checks.
> At that point we can just as well add weak typing, because, why not?
>
> We do not have an exceptional handling for return types (which are even
> more subject to be strict-only as it is function-local =E2=80=94 properti=
es may be
> public). And so we shouldn't have either for property types.
>
> Thus, my recommendation is to be consistent regarding strict and weak
> typing regarding argument and return types.
>
> > 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!
>
> Thanks,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm not 100% convinced that we need this now we have full type hint support
for parameters and return types; but it does have potential to remove
boiler plate for public properties. For point 2 nullable properties, how
about some syntax which allows for a property to be null, or for it to be a
specific type. I'd suggest a null assignment to fall in line with parameter
type hints eg:

class Foo {
    protected int $bar =3D null; //can be null
    private stdClass $baz; //can't be null
}

--001a11410bb69352de052e2dd508--