> Am 13.06.2016 um 14:36 schrieb Christoph Becker <cmbecke...@gmx.de>:
> 
> On 04.06.2016 at 16:37, Bob Weinand wrote:
> 
>>> Am 4.6.2016 um 16:17 schrieb Christoph Becker <cmbecke...@gmx.de>:
>>> 
>>> On 04.06.2016 at 14:15, Bob Weinand wrote:
>>> 
>>>>> Am 04.06.2016 um 13:45 schrieb Niklas Keller <m...@kelunik.com>:
>>>>> 
>>>>> For Aerys\Host it could also be solved with an interface that just 
>>>>> doesn't have any methods. With the disadvantage of callable not being in 
>>>>> the same signature anymore.
>>>> 
>>>> Additionally, this is only possible if you are actually in control on 
>>>> these classes and can change them. If you pull them from a library, no 
>>>> chance.
>>> 
>>> In which case it might make sense anyway to use adapters.
>> 
>> For which you then need an adapter for each and every combination of 
>> interface (power set without empty set; 2^n - 1 - 15 adapter classes for 4 
>> interfaces).
>> That’s not a practical solution here.
> 
> After having a closer look at the referenced code[1], I agree.  However,
> in this case it would still be possible to avoid overloading the
> function by having a dedicated function for each type (i.e.
> useCallable(), useMiddleware() etc.)  That doesn't appear bad to me.
> 
> [1]
> <https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7768/lib/Host.php#L87>
> 
> -- 
> Christoph M. Becker

Principally, yes, it's possible.

The reason we've chosen to not do this:
A class is often a module which may need to be callable, middleware and monitor 
at once. It allows us to have the user not know about what exactly he 
implements (in the sense of "this module is middleware and monitor"), but to 
just tell him "here's our module, just use() it and be done".
It eliminates the need of the user having knowledge of that. (=> user 
friendliness)

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to