Anyway, in 7.1 , you'll need to change your code because of the nullable feature being introduced.

• __toString() should be deprecated, and the new getName() method should be used now.
• getName() returns the name, with no '?' or things like that.
• In 7.1 , you should use getName()
• You may use isNullable() to probe if the parameter is nullable or not

You will need to change the code for new features, but old code should still reflect the same.

That's what BC is all about, and I'm kinda sick of explaining it, at this point.

Development of zendframework/zend-code, doctrine/common and ocramius/proxy-manager halted again :-\

@Ocramius If we keep the BC then zendframework/zend-code, doctrine/common and ocramius/proxy-manager get to keep working but it's basically useless for everyone else.

That's what BC breaks are all about and I'm kinda sick of explaining it, at this point.

it's basically useless for everyone else.

still need to see that "everyone else". We discussed it, and it ended up with "it's internal stuff that you can't haz".

@Ocramius So you don't respect NDAs or other forms of respecting material that aren't yours?

I agree, still, breaking few million projects (dependants) vs breaking your
internal ones, heh.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Wed, Sep 21, 2016 at 8:52 PM, Levi Morrison notifications@github.com
wrote:

@Ocramius https://github.com/Ocramius So you don't respect NDAs or
other forms of respecting material that isn't yours?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2136 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAJakKeYoBls-Sl7bKMAvxEc_YXId3uGks5qsXz8gaJpZM4KCjQx
.

If you are writing code generators I hardly think this is the most difficult BC break. In fact, I'm fairly certain you've spent more time fighting the change than it would have been to just make it compatible. You already know what to do if you are on 7.0; if you are on 7.1 just take a different code path with the new API.

Seriously, I offer right now to fix it for you as long as you'll collaborate with me on it (since I'm obviously not as familiar with the projects as you are).

I actually worked an entire week to introduce compat with void and
nullable types on just 2 of the 4 libraries I know of, and the test suit
covering those scenarios is not even complete yet.

I already fixed this shit, the point is that this shit shouldn't need
fixing in first place, since it's not a major release.

Oh, and I'm dropping PHP 7.0 support due to the complexity of maintaining
support for both 7.1 and 7.0 (just headaches).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Wed, Sep 21, 2016 at 9:01 PM, Levi Morrison notifications@github.com
wrote:

If you are writing code generators I hardly think this is the most
difficult BC break. In fact, I'm fairly certain you've spent more time
fighting the change than it would have been to just make it compatible. You
already know what to do if you are on 7.0; if you are on 7.1 just take a
different code path with the new API.

Seriously, I offer right now to fix it for you as long as you'll
collaborate with me on it (since I'm obviously not as familiar with the
projects as you are).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2136 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAJakAu_mmhdKjOxgEBXons1KbzxaKLqks5qsX8FgaJpZM4KCjQx
.

👍 for this - Prophecy is impacted for basically no reason.

We obviously have work to do to support Nullable types but breaking Foo $foo = null for existing codebases is a hard BC break and against the versioning policy.

Closing in favor of #2137
Please transfer support to this alternative PR :)