On 16 March 2016 at 17:17, Bob Weinand <bobw...@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 <pjsturg...@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 = 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 = 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…
>
> class Foo {
> public int $bar;
> function __construct() {
> global $foo;
> $foo = $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 it
> 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 — properties 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 = null; //can be null
private stdClass $baz; //can't be null
}
