Hi,
I’m coming back to this thread after some discussions about related matters
off-list. I’m firmly convinced this is a good idea, now:
* It would be very useful to extend the callable type hint to support typed
parameters and return types. If we were to do so, its validation rules should
If you consider the lack of an explicit type to mean the theoretical
Any type which is a supertype of all types then dropping the hint is
a form of contravariance. I would prefer to support normal
contravariance for parameter types in which this is just a special
case. However, I am not sure I
On Thu, Feb 5, 2015 at 2:08 AM, Andrea Faulds a...@ajf.me wrote:
Hi Hannes,
On 4 Feb 2015, at 23:58, Hannes Magnusson hannes.magnus...@gmail.com
wrote:
So what it supports more inputs?
It does constitute an LSP violation. more inputs is not what the
guarantee is at all, if that is
Hi Julien,
On 5 Feb 2015, at 12:10, Julien Pauli jpa...@php.net wrote:
If we allow larger type, why doesn't such code work ?
interface A { }
interface B extends A { }
class C {
public function foo(A $a) { }
}
class D extends C {
public function foo(B $a) { } // E_STRICT
On Thu, Feb 5, 2015 at 5:14 AM, Andrea Faulds a...@ajf.me wrote:
Hi Julien,
On 5 Feb 2015, at 12:10, Julien Pauli jpa...@php.net wrote:
If we allow larger type, why doesn't such code work ?
interface A { }
interface B extends A { }
class C {
public function foo(A $a) { }
}
class
On 5 February 2015 at 21:52, Levi Morrison le...@php.net wrote:
To chime in regarding allowing contravariant parameter types: I
struggle to find use cases for it.
Theoretically it would allow a class to implement two separate
interfaces that would otherwise be incompatible:
interface A {
On 5 February 2015 21:52:06 GMT, Levi Morrison le...@php.net wrote:
On Thu, Feb 5, 2015 at 5:14 AM, Andrea Faulds a...@ajf.me wrote:
Hi Julien,
On 5 Feb 2015, at 12:10, Julien Pauli jpa...@php.net wrote:
If we allow larger type, why doesn't such code work ?
interface A { }
interface B
Hi!
If we allow larger type, why doesn't such code work ?
interface A { }
interface B extends A { }
class C {
public function foo(A $a) { }
}
class D extends C {
public function foo(B $a) { } // E_STRICT
}
This is wrong IMO.
This shouldn't work - it means that if you
Hannes Magnusson wrote on 04/02/2015 23:58:
On Wed, Feb 4, 2015 at 10:49 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Currently we do not allow [1] removing a typehint during inheritance. For
example the following code is not valid:
interface A {
public function
On 05/02/15 13:10, Julien Pauli wrote:
On Thu, Feb 5, 2015 at 2:08 AM, Andrea Faulds a...@ajf.me wrote:
Hi Hannes,
On 4 Feb 2015, at 23:58, Hannes Magnusson hannes.magnus...@gmail.com
wrote:
So what it supports more inputs?
It does constitute an LSP violation. more inputs is not what the
Hi Nikita,
On 4 Feb 2015, at 18:49, Nikita Popov nikita@gmail.com wrote:
Currently we do not allow [1] removing a typehint during inheritance. For
example the following code is not valid:
interface A {
public function method(Typehint $param);
}
class B implements A
Nikita Popov wrote on 04/02/2015 18:49:
Hi internals!
Currently we do not allow [1] removing a typehint during inheritance. For
example the following code is not valid:
interface A {
public function method(Typehint $param);
}
class B implements A {
public
On Wed, Feb 4, 2015 at 9:04 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Nikita Popov wrote on 04/02/2015 18:49:
Hi internals!
Currently we do not allow [1] removing a typehint during inheritance. For
example the following code is not valid:
interface A {
public
On Wed, Feb 4, 2015 at 10:17 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Nikita,
On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov nikita@gmail.com
wrote:
Currently we do not allow [1] removing a typehint
Hi Nikita,
On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov nikita@gmail.com wrote:
Currently we do not allow [1] removing a typehint during inheritance. For
example the following code is not valid:
interface A {
public function method(Typehint $param);
}
class B
On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Nikita,
On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov nikita@gmail.com
wrote:
Currently we do not allow [1] removing a typehint during inheritance.
For
example the following code is not valid:
interface A {
On 4 February 2015 21:25:49 GMT, Nikita Popov nikita@gmail.com wrote:
On Wed, Feb 4, 2015 at 10:17 PM, Rowan Collins
rowan.coll...@gmail.com
wrote:
On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Nikita,
On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov
On Wed, Feb 4, 2015 at 10:49 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Currently we do not allow [1] removing a typehint during inheritance. For
example the following code is not valid:
interface A {
public function method(Typehint $param);
}
class B
Hi Hannes,
On 4 Feb 2015, at 23:58, Hannes Magnusson hannes.magnus...@gmail.com wrote:
So what it supports more inputs?
It does constitute an LSP violation. more inputs is not what the
guarantee is at all, if that is what you want you'd typehint on a
interface.
It is a LSP failure to
19 matches
Mail list logo
