Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93523
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.219 cause and error)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP2466AC64B0C1930A87E1D74E2400@phx.gbl>
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>
	<CANUQDChRE6HyKg81rsC7OW41pCuKK9WEhoai+MQq2+RUsciEGw@mail.gmail.com>
	<BLU436-SMTP2466AC64B0C1930A87E1D74E2400@phx.gbl>
Date: Wed, 25 May 2016 20:06:00 +0200
Message-ID: <CANUQDCh3TxJQAj7O87Rth-iOPn=2r3Q6QG7kLcd3GaRbQBcxWw@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11443ad8b42f130533ae864e
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: me@kelunik.com (Niklas Keller)

--001a11443ad8b42f130533ae864e
Content-Type: text/plain; charset=UTF-8

>
> Hey Niklas,
>
> > Am 25.05.2016 um 18:21 schrieb Niklas Keller <me@kelunik.com>:
> >
> >>
> >> 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/
>
> There is a difference between not set and no meaningful value.
>
> The former is literally unset(), the latter is null. The only semantics
> PHP exposes here is that not set can be upgraded to "no meaningful" value
> in form of null with a notice.
>
> The difference thus is quite minor, but semantically important.
> Hence to *set* the value, we need to explicitly set null.
>

Adding a type shouldn't alter behavior, so setting it explicitly to null
shouldn't be required.

Regards, Niklas


> If we don't do it this way, we won't have a way to explicitly *set*
> nullable properties to a value (null in this case). (without explicit unset
> in ctor).
>
> Bob

--001a11443ad8b42f130533ae864e--