I know you're already voting on this, but I'd like to throw in a
couple of late comments.
My main problem with this RFC is the use of the interface keyword for
something that almost by definition is not an interface.
An interface is a set of methods, but an anonymous function is just
one function, so it can't possibly implement an interface - this only
works because of the single method constraint and some magical mapping
of the closure as a method implementing that single-method interface.
You can't, for example, add another method to one of these
"interfaces", which is problematic - it's inconsistent with what
interfaces actually are.
In a sense, what you've really done, is you've overloaded the
interface concept as a means of shoehorning typedefs into the
language.
Per the example in the RFC:
interface IFoo {
public function method() : int;
}
$cb = function () implements IFoo : int {
return 42;
};
The coupling between $cb and IFoo is explicit - but the coupling
between IFoo::method() and the closure is implied; it's something the
interpreter, and the person reading the code, has to reason about.
The one-method limitation isn't apparent from the "interface"
declaration - that is, nothing about the interface declaration implies
that it's not actually an interface, e.g. is not a set of methods.
On the other hand, I can see the advantages of being able to treat and
invoke the closure as if it were an object implementing an interface -
it just seems like there's something missing. When a function
"implements" an interface, it puts a constraint on that interface,
preventing it from taking on another method - it imposes this
constraint on the interface from the outside-in, which seems really
counter intuitive to me.
>From the RFC:
interface IFoo {
public function method1();
public function method2();
}
function () implements IFoo {};
This is really surprising if you thought you understood what
interfaces are: a set of methods.
What suppose I write an interface that has a single method today - and
consumers of my library begin to implement this interface using
closures in this manner. But then tomorrow, I add another method to my
interface? There is suddenly now direct upgrade path, no obvious way
to fix the code - they can't simply implement that new method and move
on, they now have to start refactoring everything from closures to
actual classes.
In that sense, this is worse than typedefs - at least typedefs
consistently define precisely one function and not a set.
Another disconnect from interfaces, is that objects can traditionally
implement more than one interface - but an anonymous function can only
implement a single interface. It's another deviation from actual
interfaces, overloading the interface" keyword - it's inconsistent
with interfaces, which is misleading and adds unnecessary learning
curve.
Another downside of this proposal, is that a single functional
interface effectively has two names: the type-name and the
method-name; but both names map to the same thing, the anonymous
closure. Method-names are necessary in interfaces because they
identify the individual methods in a set of methods. But functional
interfaces are not a set of methods. The functional interface
type-name already designates the type. There is no reason it should
need to have two names.
How about the following alternative syntax?
callable IFoo = function () : int;
$cb = function () implements IFoo {
return 42;
};
With this syntactic sugar, functional interfaces are distinctly
single-method interfaces - you can't add another method.
You no longer need to come up with two names for one thing.
You don't need to repeat the return-type when implementing it.
And you don't need to specify that extra method-name when invoking it:
if ($cb instanceof IFoo) {
$number = $cb();
}
It also avoids the following conundrum:
interface Foo {
public function foo();
}
interface Bar {
public function bar();
}
class Bleet implements Foo, Bar {
// ...
}
function fluff(Bleet $bleet) {
$bleet(); // ERROR!
}
In this example, the fluff() function thinks it's getting an anonymous
function implementing Foo, but that's not the case. But it could be.
You opened that door when you decided to overload interfaces - not
only functions can implement these interfaces, classes can too.
I think this last example demonstrates a huge disconnect - you've
defined something that is apparently both an interface and a typedef
of sorts, but the resulting types are not in fact interchangible. That
is, you can't swap out an anonymous function with a class implementing
that interface, or vice-versa, unless the consumer relies on invoking
the method rather than using the object as a callable. The fact that
it's a callable isn't even a fact you can rely on anymore.
I don't believe this is good. I think that the number of compiler
errors specified in the RFC alone is a flashing red light.
I think that other languages have typedefs rather than a syntactic
version of single-method interface implementations.
Is there a source of reference for this feature? I mean another
language implementing this pattern?
I have a feeling other languages likely do not implement something like this.
I'm concerned that this might be one of those "original PHP features"
that turns out to be a little too original.
I personally would prefer to have something that's more familiar, e.g.
something close to typedefs.
Something that doesn't overload the concept of interfaces and requires
a big section in the manual explaining how interfaces in PHP are not
like interfaces in other languages, all the conditions, warnings,
acceptable use and limitations.
I'd prefer something that's simpler and easier to explain.
On Thu, May 12, 2016 at 11:14 PM, Marco Perone <m.per...@mvlabs.it> wrote:
> On 12/05/2016 19:02, Rowan Collins wrote:
>>
>> On 12/05/2016 17:47, Andreas Heigl wrote:
>>>
>>> It's the other way around.
>>>
>>> The interface creates a contract that ensures that you can use ALL
>>> methods available in your SpecialClass.
>>
>>
>> I don't think that's what the interface in the example means:
>>
>> interface Foo
>> {
>> public function foo(SpecialClass $object);
>> }
>>
>>
>> What this says is "an object adhering to interface Foo has a method foo
>> which accepts any SpecialClass instance".
>>
>> In other words, it says that the following is bound to succeed:
>>
>> if ( $thing instanceOf Foo ) {
>> $thing->foo( new SpecialClass );
>> }
>>
>>
>> Marco is right that a class with a wider definition fulfils this contract:
>>
>> class Bar implements Foo
>> {
>> public function foo(BaseClass $object)
>> {
>> // do something with BaseClass $object
>> }
>> }
>>
>> $thing = new Bar;
>> if ( $thing instanceOf Foo ) {
>> $thing->foo( new SpecialClass );
>> }
>>
>>
>> This is called "contravariance of parameters", and has come up a couple of
>> times on the list. In particular, when return types were added, it was
>> discussed that they should technically be covariant (subtypes can
>> "narrow" return types, and say they only return a specific sub-type of the
>> original contract).
>>
>> So from a design point of view, there is no reason not to support it;
>> unfortunately, there are some technical hurdles to implementing that within
>> the PHP engine. Here is a nice summary from Anthony Ferrara:
>> http://marc.info/?l=php-internals&m=142791636808421&w=2
>>
>> Regards,
>
>
> Thanks Rowan for your response and for the link, very interesting.
>
> Adding a bit of context to my question, I asked it after following a
> discussion in the FIG mailing list.
> In PSR-7 you have a RequestInterface and a ServerRequestInterface with
> inherits from it (the BaseClass and SpecialClass of my example).
> Now there is a discussion on how to standardize a MiddlewareInterface.
> You would like to have an interface like
>
> interface ServerMiddlewareInterface
> {
> public function __invoke(ServerRequestInterface $request, ...)
> }
>
> which plays the role of Foo, and maybe an implementation
>
> class MyMiddleware
> {
> public function __invoke(RequestInterface $request, ...)
> {
> // do something with $request
> }
> }
>
> which plays the part of Bar.
>
> Since at the moment Bar can not implement Foo, the solution to this is, from
> a design point of view, a bit akward (see
> https://github.com/php-fig/fig-standards/blob/95aece5e68376e9a5d79d2385d755824dfac3ed8/proposed/middleware.md#21-server-vs-client-requests
> for details). It would be nice if "variant" parameters and return types were
> introduced, so the design could be improved (this is just an example, I
> guess there could be more aroud).
>
> Regards
>
> marco
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
