Re: [PHP-DEV] Parameter type widening RFC

2017-05-30 Thread Niklas Keller
Rowan Collins schrieb am Di., 30. Mai 2017, 19:39: > On 30/05/2017 07:24, Rasmus Schultz wrote: > >> The type widening RFC makes it easier to move to parameter types for > > existing libraries. > > > > I'm curious to see how you'll set the version constraint in your > >

Re: [PHP-DEV] Parameter type widening RFC

2017-05-30 Thread Rowan Collins
On 30/05/2017 07:24, Rasmus Schultz wrote: The type widening RFC makes it easier to move to parameter types for existing libraries. I'm curious to see how you'll set the version constraint in your composer.json file. After adding a scalar type-hint to an interface, which is a breaking change

Re: [PHP-DEV] Parameter type widening RFC

2017-05-30 Thread Rasmus Schultz
> The type widening RFC makes it easier to move to parameter types for existing libraries. I'm curious to see how you'll set the version constraint in your composer.json file. After adding a scalar type-hint to an interface, which is a breaking change in 7.0 and 7.1, but a non-breaking change in

Re: [PHP-DEV] Parameter type widening RFC

2017-05-29 Thread Rowan Collins
On 28/05/2017 18:06, Aidan Woods wrote: So, if I understand everything here correctly ``` interface Foo { public function bar(Boo $Boo); } ``` and ``` interface Foo { /* * @param $Boo, pretty please accept type Boo here */ public function bar($Boo); } ``` will be equivalent

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread Dan Ackroyd
On 28 May 2017 at 14:25, Rasmus Schultz wrote: > > To me, that's a setback that leads to harder-to-debug errors, and increases > learning-curve. Everything is a trade-off. The type widening RFC makes it easier to move to parameter types for existing libraries. While I can

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread li...@rhsoft.net
Am 28.05.2017 um 23:28 schrieb Dan Ackroyd: On 28 May 2017 at 18:06, Aidan Woods wrote: So, if I understand everything here correctly ... will be equivalent in 7.2? :( Not equivalent. Adding the Boo param type to an implementation, when it is only a comment in the

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread Dan Ackroyd
On 28 May 2017 at 18:06, Aidan Woods wrote: > So, if I understand everything here correctly > ... > will be equivalent in 7.2? :( > Not equivalent. Adding the Boo param type to an implementation, when it is only a comment in the parent gives an error. interface Foo { /*

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread Aidan Woods
So, if I understand everything here correctly ``` interface Foo { public function bar(Boo $Boo); } ``` and ``` interface Foo { /* * @param $Boo, pretty please accept type Boo here */ public function bar($Boo); } ``` will be equivalent in 7.2? :( Regards, Aidan On 28 May 2017 at

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread Rowan Collins
On 28/05/2017 14:25, Rasmus Schultz wrote: With an explicit mixed type-hint, you can still achieve what you want You are making a valid point in general, but you clearly haven't read or understood the explanations you've been given why an explicit mixed type-hint will NOT achieve what the

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread Rasmus Schultz
Alright, here's an example of code where a type-hint was accidentally left out. Before this change: https://gist.github.com/mindplay-dk/e988902ed2d587dc05a1d8cb164b88c4/4d03babff16883a67accfb51b50e3d1aefb13a8a And after this change:

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread Christoph M. Becker
On 28.05.2017 at 12:30, Rasmus Schultz wrote: > In my opinion, this will very likely lead to a large number of accidental > type-hint omissions - and a very, very small number of actually useful > solutions to real problems. > > In my opinion, we can do much better than that, by adding a mixed >

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread Niklas Keller
2017-05-28 12:30 GMT+02:00 Rasmus Schultz : > > > So this breaks the expected behavior of interfaces. > > > > No it doesn't. It allows interfaces to use contravariance within PHP's > > type system, which is different from before, but it doesn't break > > anything. > > The RFC

Re: [PHP-DEV] Parameter type widening RFC

2017-05-28 Thread Rasmus Schultz
> > So this breaks the expected behavior of interfaces. > > No it doesn't. It allows interfaces to use contravariance within PHP's > type system, which is different from before, but it doesn't break > anything. The RFC explicitly states that this is *not* contravariance. And if it's not clear,

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread li...@rhsoft.net
Am 26.05.2017 um 18:10 schrieb Ryan Pallas: On Fri, May 26, 2017 at 9:01 AM, li...@rhsoft.net > wrote: Am 26.05.2017 um 16:26 schrieb Dan Ackroyd: On 26 May 2017 at 13:23, li...@rhsoft.net

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread Ryan Pallas
On Fri, May 26, 2017 at 9:01 AM, li...@rhsoft.net wrote: > > > Am 26.05.2017 um 16:26 schrieb Dan Ackroyd: > >> On 26 May 2017 at 13:23, li...@rhsoft.net wrote: >> >>> does that also fix the issue https://bugs.php.net/bug.php?id=74394 >>> >> >> >> Dear

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread li...@rhsoft.net
Am 26.05.2017 um 16:26 schrieb Dan Ackroyd: On 26 May 2017 at 13:23, li...@rhsoft.net wrote: does that also fix the issue https://bugs.php.net/bug.php?id=74394 Dear Anonymous, That "issue" is actually 3 issues. case 1 class A { public function test($a) {} } class B

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread Dan Ackroyd
On 26 May 2017 at 13:23, li...@rhsoft.net wrote: > does that also fix the issue https://bugs.php.net/bug.php?id=74394 Dear Anonymous, That "issue" is actually 3 issues. case 1 class A { public function test($a) {} } class B extends A { public function test(string $a) {

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread li...@rhsoft.net
Am 26.05.2017 um 14:16 schrieb Christoph M. Becker: On 26.05.2017 at 12:16, Niklas Keller wrote: 2017-05-26 10:35 GMT+02:00 Andrey Andreev : On Thu, May 25, 2017 at 11:02 PM, Dan Ackroyd wrote: The RFC specifically didn't mention LSPbecause

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread Christoph M. Becker
On 26.05.2017 at 12:16, Niklas Keller wrote: > 2017-05-26 10:35 GMT+02:00 Andrey Andreev : > >> On Thu, May 25, 2017 at 11:02 PM, Dan Ackroyd >> wrote: >>> >>> The RFC specifically didn't mention LSPbecause that is separate >>> from

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread Niklas Keller
2017-05-26 10:35 GMT+02:00 Andrey Andreev : > Hi, > > On Thu, May 25, 2017 at 11:02 PM, Dan Ackroyd > wrote: > > > > The RFC specifically didn't mention LSPbecause that is separate > > from co/contravariance. It's unfortunate for other people to be >

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread Nikita Popov
On Fri, May 26, 2017 at 10:35 AM, Andrey Andreev wrote: > Hi, > > On Thu, May 25, 2017 at 11:02 PM, Dan Ackroyd > wrote: > > > > The RFC specifically didn't mention LSPbecause that is separate > > from co/contravariance. It's unfortunate for other

Re: [PHP-DEV] Parameter type widening RFC

2017-05-26 Thread Andrey Andreev
Hi, On Thu, May 25, 2017 at 11:02 PM, Dan Ackroyd wrote: > > The RFC specifically didn't mention LSPbecause that is separate > from co/contravariance. It's unfortunate for other people to be > throwing the two around at you with a lack of precision. > Perhaps this

Re: [PHP-DEV] Parameter type widening RFC

2017-05-25 Thread Dan Ackroyd
Andrey Andreev wrote: > When I said I don't claim to fully understand LSP Hi Andrey, The RFC specifically didn't mention LSPbecause that is separate from co/contravariance. It's unfortunate for other people to be throwing the two around at you with a lack of precision.

Re: [PHP-DEV] Parameter type widening RFC

2017-05-25 Thread Fleshgrinder
On 5/25/2017 6:38 PM, Andrey Andreev wrote: > Sorry, but by "source" I didn't mean somebody state it here. :) > > When I said I don't claim to fully understand LSP, I didn't mean "tell > me what it is" - I'm familiar with it. What I don't understand is how > do we get from this: > >> Wikipedia:

Re: [PHP-DEV] Parameter type widening RFC

2017-05-25 Thread Andrey Andreev
Hi Marco, On Thu, May 25, 2017 at 6:58 PM, Marco Pivetta wrote: > On Thu, May 25, 2017 at 4:30 PM, Andrey Andreev wrote: >> >> I'm trying, but fail to find a source that says replacing stdClass >> with mixed/any/etc is ok. > > > It is OK for a subtype to

Re: [PHP-DEV] Parameter type widening RFC

2017-05-25 Thread Marco Pivetta
On Thu, May 25, 2017 at 4:30 PM, Andrey Andreev wrote: > I'm trying, but fail to find a source that says replacing stdClass > with mixed/any/etc is ok. It is OK for a subtype to handle a wider range of types than its contract, it is not ok for the subtype to handle a smaller

Re: [PHP-DEV] Parameter type widening RFC

2017-05-25 Thread Andrey Andreev
Hi, On Tue, May 23, 2017 at 10:38 PM, Fleshgrinder wrote: > > I also had a look at the GitHub discussion, and I think that the things > that were written there have nothing to do with your concern. The people > commenting there simply did not understand LSP. > Well,

Re: [PHP-DEV] Parameter type widening RFC

2017-05-25 Thread Dan Ackroyd
On 25 May 2017 at 10:21, Rasmus Schultz wrote: > So this breaks the expected behavior of interfaces. No it doesn't. It allows interfaces to use contravariance within PHP's type system, which is different from before, but it doesn't break anything. Niklas Keller wrote: > The

Re: [PHP-DEV] Parameter type widening RFC

2017-05-25 Thread Rasmus Schultz
> > The feature, as implemented, will allow accidental omission of type-hints, > > will it not? > > Yes, correct. So this breaks the expected behavior of interfaces. This will be harmful to everyone, but especially harmful to new programmers, who may never even learn how to correctly implement

Re: [PHP-DEV] Parameter type widening RFC

2017-05-23 Thread Levi Morrison
On Tue, May 23, 2017 at 1:25 PM, Rasmus Schultz wrote: > > I feel like this feature takes a pretty dangerous shortcut by simply > removing a constraint check that we used to have - in favor of supporting a > few rare cases, we removed a guarantee that interfaces and the >

Re: [PHP-DEV] Parameter type widening RFC

2017-05-23 Thread Niklas Keller
Hi Rasmus, > This parameter type widening RFC, I didn't know about, but I have a remark. > > The feature, as implemented, will allow accidental omission of type-hints, > will it not? > Yes, correct. > Previously, the implements keyword guaranteed a correctly type-hinted > implementation -

Re: [PHP-DEV] Parameter type widening RFC

2017-05-23 Thread Fleshgrinder
On 5/23/2017 9:51 PM, Nikita Popov wrote: > One of the primary motivations behind this RFC is to allow the addition of > typehints (for example in library code) without introducing a backwards > compatibility break for any code implementing or extending your > interface/class. Requiring an

Re: [PHP-DEV] Parameter type widening RFC

2017-05-23 Thread Nikita Popov
On Tue, May 23, 2017 at 9:25 PM, Rasmus Schultz wrote: > This parameter type widening RFC, I didn't know about, but I have a remark. > > The feature, as implemented, will allow accidental omission of type-hints, > will it not? > > Previously, the implements keyword guaranteed

Re: [PHP-DEV] Parameter type widening RFC

2017-05-23 Thread Fleshgrinder
On 5/23/2017 9:25 PM, Rasmus Schultz wrote: > This parameter type widening RFC, I didn't know about, but I have a remark. > > The feature, as implemented, will allow accidental omission of type-hints, > will it not? > > Previously, the implements keyword guaranteed a correctly type-hinted >

[PHP-DEV] Parameter type widening RFC

2017-05-23 Thread Rasmus Schultz
This parameter type widening RFC, I didn't know about, but I have a remark. The feature, as implemented, will allow accidental omission of type-hints, will it not? Previously, the implements keyword guaranteed a correctly type-hinted implementation - it's now possible to (purposefully,