Something like is more readable

BTW, the code when$ack === null seems broken: You create a newAcknowledger, so the$ack argument in it is null, so it's an empty callable, so it never reallyack on the transport?

I think this part can be simplified

Patch applied thanks.

This logic is the answer to your question:

as soon as I implement the interface, the handler is forced to be used in batch mode?

when$ack isnull,HandleMessageMiddleware will not add theNoAutoAckStamp, and the worker will ack as usual. The batch handler is thus compatible with non-batch mode.

I still want to simplify this PR and I think something could be done here.

This trait is namedBatchHandlerTrait so its purpose is to handle batches of messages. I understand that you want to preserve the contact in theHandlerInterface. But this very method must not allow to pass$ack=null.

So basically, If one wants to use the handler in a batch way and also in a non batch way (which is not possible BTW), it does not make sens when$ack === null (in the$handler::__invoke()) to callhandle().

So this trait must throw an exception when $ack is null. And it's up to the developer to check if$ack is null or not, and if it's null they must not call this method.

Finally, all cases where$ack === null could be removed (here, and inAcknowledger).

• the code will be simpler, and easier to read / lean
• the contract ofHandlerInterface::__invoke($message) (where$ack = null) is preserved
• I'm happy

And by doing so, we can renamed handle() (which is very generic and not really intuitive) toschedule(). (see my comment on the current schedule method).

I really like the following code / API:

class Handlerimplements BatchHandlerInterace{publicfunction__invoke(Message$message,$ack)  {if ($ack) {return$this->schedule(newFoobar($message),$ack);    }// sync processing  }}

Don't you?

I don't agree with throwing. The handler should be usable in non-batch mode per LSP and throwing would break that. The current design makes it a no brainer: implementprocess() and no need to care about this concern. Your proposal would require ppl to write extra logic if they want to follow LSP. But LSP is not an option to me.

I don't agree with throwing. The handler should be usable in non-batch mode per LSP and throwing would break that.

Yes, I totally agree with you on that point

The current design makes it a no brainer

I disagree with you. You may think it's easy, but people read code under the hood. and ATM, the code is not simple.

Your proposal would require ppl to write extra logic

Yes one more line of code. Explicit is better than implicit

But LSP is not an option to me.

I don't understand why LSP may be broken. Can you elaborate?

The boilerplate to implement both modes is in the trait. That's how it should be. Not doing so means requiring every consumer of the trait to add the same boring logic. That'd fail the purpose of the trait, and more critically, that'll break LSP when ppl won't implement the "else" in your snippet. Since we know ppl are lazy, or make mistakes, this is a recipe for more bugs.

About LSP, the principle is not about php interfaces but about abstractions that should be swappable. If an implementation fails to implement non-batch mode, eg by throwing, then it's not swappable and LSP is broken.