Hi all,

   first up, major thanks to both Joe and Phil for putting this together.
I'm fully behind the concept of typed properties and think it would be a
great feature to have in the language.

I have a few points I'd like to make on the current implementation being
proposed.

1) There's an issue with the way the __get magic method works. I understand
this has been introduced from allowing unset on typed properties (because
of the reasons Marco mentioned previously), however it's still something I
feel needs addressing:

class Foo
{
    public int $bar;
    public function __get($name)
    {
        return 123;
    }
}

$foo = new Foo();
unset($foo->bar);
var_dump($foo->bar);   // int(123)

$foo = new Foo();
var_dump($foo->bar);  // Fatal error: Uncaught TypeError: Typed property
Foo::$bar must not be accessed before initialisation

I'd consider the fact that var_dump($foo->bar); produces different things
here a bug. They're both unset/uninitialised and should produce the same
result. Which in my opinion should be "int(123)", but i'll get onto that in
a bit.


2) Having a guarantee that a variable is of a certain type has a ton of
benefits, mostly that you don't have to add defensive code to check its
type. As Larry pointed out, littering your code based with !is_null() is
not a nice thing to have to do.

Unfortunately typed variables will at some point be uninitialised. you
can't really force the developer to set them (either at construct or later)
as this is something that should in my opinion always belong at
implementation and not baked in/forced at the language level. With this in
mind, handling uninitialised state will always be a thing that needs to be
done. We can't really guarantee that the property was set up properly, or
start to return a default value of said type.

Further to this, and the fact that the ability to unset typed properties
has been reintroduced it now becomes possible to initialise a property,
have it unset and get TypeError's on subsequent access (where no __get() is
provided). So even after initialisation we can never be 100% sure a
property hasn't been destroyed and contains the type you'd expect.

As it doesn't appear there's any way we can actually provide this
guarantee. I'd suggest removing TypeError's on access as it's superfluous.
This would then solve my first point as the magic method would be called as
expected. I know this isn't ideal, but the type check on set is still very
powerful and still provides a guarantee that you have either an
uninitialised property, or a one of a type you'd expect.

3) One final small point; it would be great if we could also have typed
properties outside the scope of a class. Not a show stopper by any means,
but certainly a nice to have.

That's all. Again thanks so much for putting this together.

Lee

/@leedavis81

On Wed, Mar 16, 2016 at 4:36 PM, Phil Sturgeon <pjsturg...@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!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Reply via email to