Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.162 cause and error)
MIME-Version: 1.0
In-Reply-To: <7B.12.14311.F79C5475@pb1.pair.com>
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>
	<7B.12.14311.F79C5475@pb1.pair.com>
Date: Wed, 25 May 2016 18:21:29 +0200
Message-ID: <CANUQDChRE6HyKg81rsC7OW41pCuKK9WEhoai+MQq2+RUsciEGw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b86db22ecd2720533ad1030
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: me@kelunik.com (Niklas Keller)

--047d7b86db22ecd2720533ad1030
Content-Type: text/plain; charset=UTF-8

>
> 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.
>

Null shouldn't have any meaning apart from "not set". It should never be a
meaningful value.


> 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/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--047d7b86db22ecd2720533ad1030--