PHP lacks of enterprise engineering over the language, and that is the problem. You're not resolving the holism in the language, but rather a specific part without consider the whole.
Yes, it makes sense to support ?Foo for and only for return types, but what about everything else? What about future scope? Sure, future scope is unknown, but we do have scope that is currently being defined, you're even debating over it and it'll severely impacted by this small little support that we're adopting right now only for this specific case. The problem of not thinking in the language as a whole and just fixing small bits every time lead to the inconsistency hell we live today. So please, step back and look over that introducing this tiny language enhancement will impact final properties, typed properties and add a language inconsistency with already defined standard (instanced may be absent of value like in function parameters). If you don't think what I'm saying is true, look at return type hint and how you define parameter type hint. And with typed properties (as the patch currently stands), it will follow parameter type hint instead of return type hint. Regards, On Wed, Apr 20, 2016 at 12:13 PM, Dmitry Stogov <dmi...@zend.com> wrote: > What we really miss now, is an ability to define nullable return types. > > > https://wiki.php.net/rfc/nullable_return_types > > > I don't care about the same notations for arguments (and everything else), > because we already may use NULL default value. > > However usage of "?" for arguments also may make sense. Someone may like > this, someone not. > > > Thanks. Dmitry. > > ------------------------------ > *From:* guilhermebla...@gmail.com <guilhermebla...@gmail.com> > *Sent:* Wednesday, April 20, 2016 18:05 > *To:* Lin Yo-An > *Cc:* Dmitry Stogov; Tom Worster; internals > *Subject:* Re: [PHP-DEV] [RFC] Nullable Types > > I read the RFC and I want to highlight why I'll vote -1 on it even before > it goes to voting. > > IMHO, it looks backwards to what the language is progressing. The > introduction of nullable type hint as a separate notation than a simple > type hint makes it *very* hard to implement typed properties, factory > methods and constructor verifications. > > Dmitry is even involved in the discussion of having IS_UNDEF until > constructor ends, then enforcing type hinting at the end of constructor to > trigger potential invalid instance state. It created a mess in the internal > structure by creating a 3-state value: uninitialized, absent of value > (null) and assigned value. All this problem would be solved by merging null > into accepted value. > So far the proposed solution there to take a wrong assumption to assume a > default value based on type defined (like int = 0, string = '', etc), which > are all potential valid values, leading to unpredictable behavior if a > develop misses to assign a value to that property. > > Sure, people will say that now PHP will require a NullPointerException, > PHP is turning into Java, or that I don't know what I'm talking about > because they coded for Amiga and I don't (yes, I've seen that already in > this mailing list). But the fact is that keeping control of 3-state flags > are hard to maintain. > > Constructor verifications is actually a completely different subject that > shouldn't be considered as part of typed properties, but for final > properties (or whoever other keyword someone think is smarter because > *reasons*). It's bad to bring this already to typed properties, specially > because of its runtime performance impact. > > Now let's say we move forward with nullable type hint, ignore everything > what I said and move forward. Congratulations, we just created a language > inconsistency. Example: > > function foo(Bar $bar = null); > > Why now I have 2 ways to define a nullable value? Shouldn't this be > changed into this: > > function foo(?Bar $bar); > > But of course, changing this would be a BC break and should be left for > *reasons*. But accepting the absence of value (null) as a valid value, it > would address the language inconsistency (the current support would be > kept, so no BC break), and would solve a huge mess that typed properties > patch currently needs to solve. Ah, and we don't continue into this path of > madness where same thing have 144 different ways in different areas to be > defined. > > > Regards, > > On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An <cornelius.h...@gmail.com> > wrote: > >> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmi...@zend.com> wrote: >> >> > The grammar is taken from HHVM. >> > Using any other would make more mess. >> > >> I agree >> > > > > -- > Guilherme Blanco > Lead Architect at E-Block > -- Guilherme Blanco Lead Architect at E-Block
