"Delegate should conflict with Middleware" argument appears unfounded

[schnittstabil]

Current version:

5.2 Delegate Design

Why does the delegate conflict with middleware?

Both the middleware and delegate interface define a process method to prevent misuse of middleware as delegates.

Unfortunately, the statement above is not supported by any arguments or explanations within the README.md.

More precisely, the README.md lacks answers to the following questions:

1. If a middleware is used as a delegate, why must that be considered a misuse?
2. What kind of misuse? Do we have a technical term for that?
3. Who will be hurt by the misuse?
   1. Does the misuse prevent middleware dispatchers from working correctly?
   2. Does the misuse prevent middlewares from working correctly?
4. Why should/must we prevent those misuses by a name conflict?
   1. Why does different method names necessarily lead to misusable classes?
   2. Why does different method names necessarily lead to a misuse?
   3. Does a name conflict safely prevent us from those misuses?

[schnittstabil]

The mentioned sentence is the very only explanation why delegate conflict with middleware and it is not supported by any arguments within the README.md.

@shadowhand Using your own words at https://github.com/http-interop/http-middleware/pull/57#issuecomment-272486478:

What may be obvious to you is not necessarily obvious to others.

Hence, why did you closed this issue without any explanation?

[schnittstabil]

Clarification

Two issues (4. i. and 4. ii.) are similar to #55. The highlighted necessarily is important above. Just because one can do something does not necessarily imply he will. For example:

Barack Obama can launch atomic bombs, but that does not necessarily imply he will!

@shadowhand If you believe that we have to protect developers from themselves, then we have to state that clearly. For example:

If the middleware and delegate interfaces define methods with different names, then developers may create middlewares which can also be used as delegates. We believe this would be a misuse with negative impact on the PHP ecosystem and therefore should not be allowed.

While I disagree with that statement itself, the reasons would be more comprehensible for the reader.

[schnittstabil]

For what it's worth, an example of a middleware that can also act as a delegate, without violating SRP (or Separation of concerns):

trait MiddlewareDecoratorTrait
{
    abstract function handle(ServerRequestInterface $request);

    public function process(ServerRequestInterface $request, DelegateInterface $delegate)
    {
        return $this->handle($request);
    }
}

trait DefaultResponseTrait
{
    public function handle(ServerRequestInterface $request)
    {
        return new \Zend\Diactoros\Response();
    }
}

class DefaultResponseHandler implements DelegateInterface, ServerMiddlewareInterface
{
    use MiddlewareDecoratorTrait;
    use DefaultResponseTrait;
}

Using the following interfaces without name conflict:

interface DelegateInterface
{
    public function handle(ServerRequestInterface $request);
}

interface ServerMiddlewareInterface
{
    public function process(ServerRequestInterface $request, DelegateInterface $delegate);
}