Morning Lee,
Phil is in a field somewhere, but I don't want to leave you hanging on for
an answer ... so ...
class Foo
{
public $bar;
public function __get($name)
{
return 123;
}
}
$foo = new Foo();
var_dump($foo->bar);
You should not expect __get to be called in this example code; __get is
only invoked when the property is undefined.
That's what unset does; It doesn't just destroy the value, but tells the
engine that the property is not declared (leaves it undef), which is what
results in the subsequent invocation of __get upon access to the unset
property.
Accessing the property before it was unset though, as it always did,
attempts to read the default value (null).
We haven't changed any of that ...
If $bar were typed, it would obviously be unacceptable to return anything
other than a value of the declared type upon access, so we must not allow
return to happen if there is no value on a typed property, because it's an
obvious violation.
Accessing a typed member before there is any possible chance the variable
was set is a programmer error - colloquially known as "use before
initialization" - a very common programming error, which we helpfully raise
an exception for.
Accessing a typed member after they were unset is another programming error
- "use after free" - again, we helpfully raise an exception.
In both of these circumstances, raising an exception is the only possible
action; Anything else really would constitute a change to the way objects
work, and or a violation of the type declared.
The most you can say about this, is that it's strange that the same
exception is raised for both cases, which we're aware of; Right now, it's
impossible to distinguish between the two states.
The things you can be sure of:
- If you get a value from an access of a typed property, it is the
correct type.
- If you get exceptions, you have logical errors in your code.
Cheers
Joe
On Fri, Mar 18, 2016 at 8:39 PM, Lee Davis <leedavi...@gmail.com> wrote:
> 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
> >
> >
>
