Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91765
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAHZ_-MDTKBMPSOWEQ4Ba3QKsiQfupYTnnU-ca6yZ7aizUqmFJQ@mail.gmail.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
	<CAHZ_-MCOkz1m5zPRQA6Uf=kmF=70949djRdFtkqi5O71yqJ+pg@mail.gmail.com>
	<CAL=_i_=MAQAd-5uKXTJv_M8X-EKjMXXqYkY3mpkLS4E3n0SaLQ@mail.gmail.com>
	<CAHZ_-MDTKBMPSOWEQ4Ba3QKsiQfupYTnnU-ca6yZ7aizUqmFJQ@mail.gmail.com>
Date: Sat, 19 Mar 2016 09:51:06 +0000
Message-ID: <CAL=_i_mq0VoygXeyB9sqLHGCdZQHd2vsH=JzC3uqQNHE74DzWw@mail.gmail.com>
To: Lee Davis <leedavis81@gmail.com>
Cc: Phil Sturgeon <pjsturgeon@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114c7862662750052e63cd5f
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: pthreads@pthreads.org (Joe Watkins)

--001a114c7862662750052e63cd5f
Content-Type: text/plain; charset=UTF-8

Morning Lee,

> Makes sense. AccessTypeError, WriteTypeError to both extend TypeError?

Well maybe ... I'm not sure there is much purpose in distinguishing between
the two, while the engine doesn't make the distinction for normal untyped
properties.

If we make the distinction for typed properties, why do untyped ones behave
differently ?

We have to make every effort for typed and untyped properties to be
consistent with each other, even if strange ...

> I'd still prefer the TypeError to only occur on setting rather than on
access as well

This would provide the opportunity for you to violate the declared type:

$foo = new class {

    public int $bar = 10;

    public function __construct() {
        unset($this->bar);
    }

    public function __get($name) {
        return "oh dear!";
    }
};

var_dump($foo->bar);

In order to provide those "perfect" guarantees we must not allow that to
happen.

Zend objects aren't just full of the magic you know about in user land,
they can work in all kinds of strange and wonderful ways: Bottom line, the
value you wrote doesn't have to be the one returned when you read, for all
kinds of reasons.

The fact is the check is extremely cheap and without them, declaring the
type of the property in the first place would be pointless.

Cheers
Joe


On Sat, Mar 19, 2016 at 9:17 AM, Lee Davis <leedavis81@gmail.com> wrote:

> Hi Joe,
>
>
>> 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 ...
>>
>
>
> Yes, you're right, this is exactly how it currently behaves :
> https://3v4l.org/YpfYe (apologies for not checking this first).
> Still seems inconsistent, but that's now outside the scope of the RFC.
>
>
>> 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.
>>
>
> Makes sense. AccessTypeError, WriteTypeError to both extend TypeError?
>
>
>>
>> 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.
>>
>
> Perfect. I'd still prefer the TypeError to only occur on setting rather
> than on access as well (along with a fair amount of others:
> https://twitter.com/leedavis81/status/710872866556874753), this would
> then have the RFC only concerned itself with the WHAT rather than the WHEN,
> but as long as that promise can be upheld then it's a great feature to have.
>
> I think adding in rules at the language level to dictate when it should be
> set (i.e after construct) is a bad move, so I'd be in favour of leaving it
> as it stands at the moment. Property accessors could solve the problem of
> uninitialised properties later on.
>
> Cheers for all your hard work guys,
>
> Lee
> /@leedavis81
>

--001a114c7862662750052e63cd5f--