Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96070
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAOWwgpmjaYnsOcJ2_vACCpR95NNQk8C_PwyWtdwOA-s5FbfpSg@mail.gmail.com>
References: <CAOWwgpn1_ZHxQq9FpiwCYoqT3kVHH0k3LgO7E+eX5N2ybjDtrg@mail.gmail.com>
 <CAF+90c9XW7G-7CtKCWt+JOm5vE1XTnC92AkHvmBe9fohTOWeKA@mail.gmail.com>
 <CAOWwgpm6YL+kiwT=n8QdeKHVYg=KG7aCp=2Cv5qn0nRVNwR0bA@mail.gmail.com>
 <CAObuZduNr1oKRx0MKdGG=9XLADZF_tP4YORTk486kWa6CC_=Hg@mail.gmail.com> <CAOWwgpmjaYnsOcJ2_vACCpR95NNQk8C_PwyWtdwOA-s5FbfpSg@mail.gmail.com>
Date: Wed, 21 Sep 2016 10:54:51 -0600
Message-ID: <CAObuZdvjesE9=C8sFk_8wdbpUzu7g2CTUY6Js_mSitO6SbB2=Q@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114cbf145ed233053d0767f3
Subject: Re: [PHP-DEV] Fix ReflectionType::__toString() BC break
From: derokorian@gmail.com (Ryan Pallas)

--001a114cbf145ed233053d0767f3
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 21, 2016 at 10:34 AM, Nicolas Grekas <nicolas.grekas@gmail.com>
wrote:

>
>
>> I'm not so sure its a BC though. Technically nullable types don't exist
>> in 7.0 and as such would be impossible to return said question mark. Its
>> only adding support for a new feature, not changing how an existing feature
>> works IMO. If nullable types had been in 7.0 its highly probably, that
>> __toString would have returned the leading question mark back then.
>>
>
> Here is the BC break: https://3v4l.org/VUbIS
>
> As light as it looks to be, the output on PHP7.1RC2 is not the same as in
> PHP7.0.
> Yet, __toString() is the only public interface that is available on PHP
> 7.0,
> so people have already built things on top.
>
>
I get that the output changed, but so did the type definition with the new
feature.

However, I feel this is a problem with the way types are inferred. To me
Type $foo = null is an entirely different definition than ?Type $foo, but
that's not how its implemented in the language. To me Type $foo = null
should say "I have a parameter that is not required, but when its passed it
needs to be an instance of Type", whereas ?Type $foo should say "I require
this parameter, and it needs to be an instance of Type or null". If these
definition were the result of those expressions, then we could have a third
state, namely ?Type $foo = null which would say "I do not require this
parameter, but when its passed it needs to be an instance of Type or null".
I think the reason it works this way is, get this, for BC since previously
Type $foo = null was the only way to make a parameter nullable, while
having the intentional or unintentional side effect of making it optional
(or the only way to make it optional, while having the side effect of
making it nullable).

However, given the current workings, Type $foo = null IS in fact nullable,
therefore the string representation of that type is in fact ?Type. To
handle this in code written around current __toString seems pretty simple:

$type = method_exists($RefType, 'getName') ? $RefType->getName() : (string)
$RefType;

Given how simple that is, I'm not understanding what makes it such a big
deal for you (or anyone else) either?


>
> Nicolas
> p.s. to Nikita: my bad for the too short quote...
>

--001a114cbf145ed233053d0767f3--