2016-12-18 10:38 GMT+01:00 Wes :
> Good morning nice internals PHPeople,
>
> I have just written a new RFC. I believe is mostly about cosmetic changes,
> as what is being proposed is probably already informally supported by PHP.
>
> I would like your opinion about it:
>
Hey Wes,
On Sun, Dec 18, 2016 at 12:03 PM, Wes wrote:
> Will be nice to have regardless if PHP gets stuff like enums. It's not
> just a dirty fix.
>
> Strictly speaking it is not a BC change because `int` is not actually
> enforced at all. Also this would be a problem in
Will be nice to have regardless if PHP gets stuff like enums. It's not just
a dirty fix.
Strictly speaking it is not a BC change because `int` is not actually
enforced at all. Also this would be a problem in other languages...
function bar(): int{
mixed $code = (new MyException)->getCode();
Fix one library or fix all of them: good luck with the second one.
Anyway, the type change (on the property, in this case) can be applied to
any interface change reducing return type strictness: it is a BC break.
On 18 Dec 2016 11:47 a.m., "Wes" wrote:
> Yo, Marco :P I
Yo, Marco :P I don't need to add any contextual data, I'm just trying
improve consistency by formalizing what PHP already does. I think it's the
right way to fix this because I don't think changing PDO is ever going to
happen. You either special case PDO in your code or formalize the special
case
Looks like a step backwards to me. In fact, I just had issues with code (in
zendframework https://github.com/zendframework/zend-servicemanager/pull/167)
that assumed integer error codes, but then failed because PDO failed to
adhere to the property specification (PDO needs fixing here, not the
Good morning nice internals PHPeople,
I have just written a new RFC. I believe is mostly about cosmetic changes,
as what is being proposed is probably already informally supported by PHP.
I would like your opinion about it:
https://wiki.php.net/rfc/throwable-code-generalization
Thank you.