Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93509
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7B.12.14311.F79C5475@pb1.pair.com>
To: internals@lists.php.net
References: <CAL=_i_mcJoFnPgeU5FQCJN=SDYnNK7Jz8zoVMv9EMuWaGRYSMg@mail.gmail.com>
 <BY2PR0201MB17845690B6386D75AF4C3D79BF4F0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAL=_i_=EqNoHvXmY+RdQW-reC4YF8AkuWFtGGJGOOSqX4a010g@mail.gmail.com>
 <cfe8404a-54f6-24b7-0ba8-8f807c820821@zend.com>
 <CAL=_i_kze8MNSmpg4WT+EJCRPmvty=8DA6DkuHSx+WCBzJjytg@mail.gmail.com>
 <CAF+90c9cBqKfy_q5rME1u56Rq366niYUBDTY+3_2iFJSZD9fDA@mail.gmail.com>
 <CANUQDCj0O6aVwTqo+CcAbX8AWvwPQHfhRtsYRUrMS_aFjHM5RQ@mail.gmail.com>
Date: Wed, 25 May 2016 16:49:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0)
 Gecko/20100101 Firefox/43.0 SeaMonkey/2.40
MIME-Version: 1.0
In-Reply-To: <CANUQDCj0O6aVwTqo+CcAbX8AWvwPQHfhRtsYRUrMS_aFjHM5RQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: ajf@ajf.me (Andrea Faulds)

Hi Niklas,

Niklas Keller wrote:
>
> I disagree here. Properties are always null by default. The current patch
> disallows
> access to uninitialized variables only if they're not nullable, since null
> isn't a valid value then.
>
> I don't think having to explicitly set them to null is the think we want.
> And it's not what I'd expect given the current system.

PHP's existing untyped properties are implicitly initialised to null, 
and so yes, we would essentially only be copying our existing behaviour.

However, I think it is worth asking whether our existing behaviour is 
useful before we preserve it here. From my perspective, it is unhelpful 
that PHP does not warn you about using properties you haven't 
initialised, and this applies to both typed and untyped properties. In 
some cases (like in my linked list example in a previous email), null 
might be a meaningful value and worth distinguishing from a property not 
having being initialised yet.

We can't change the behaviour of our existing untyped properties (or at 
least, that's beyond the scope of this RFC), but we could choose the 
behaviour we find more useful for our typed properties.

Consider that we did something like this for parameters. Not providing 
an untyped parameter gives an E_WARNING:

$ php -r 'function foo($a) {} foo();'
PHP Warning:  Missing argument 1 for foo(), called in Command line code 
on line 1 and defined in Command line code on line 1

But not providing a typed parameter gives a TypeError:

$ php -r 'function foo(int $a) {} foo();'
PHP Fatal error:  Uncaught TypeError: Argument 1 passed to foo() must be 
of the type integer, none given, called in Command line code on line 1 
and defined in Command line code:1
Stack trace:
#0 Command line code(1): foo()
#1 {main}
   thrown in Command line code on line 1

So there's a precedent for applying stricter rules when type 
declarations are used.

Thanks!


-- 
Andrea Faulds
https://ajf.me/