I find it confusing: my original assumption would have been that the other arguments are other messages, in case I want to dispatch multiple of them at the same time. I know it's been done this way on Envelope::__constructor but looking back, I'm not convinced.

This is much more explicit:

$bus->dispatch(
   new Envelope(new SendSmsNotification('Hi!'))
       ->with(new DelayStamp(10), new QueueNameStamp('low'))
);

Or if it's really important, let's make it an array so we identify easily that it should not be other messages?

$bus->dispatch(
   new SendSmsNotification('Hi!'),
   [ new DelayStamp(10), new QueueNameStamp('low') ]
);

Hmm, fair point. Wrapping it in an array still looks great to me, and indeed, a bit more clear. I can change to use that if others agree.

I agree that using an array. looks a bit better.

I suggest we change the Envelope::__construct 2nd argument as well.

This is ready to go:

• 2nd arg added to MessageBusInterface: array $stamps = []
• "2nd" arg on Envelope changed from StampInterface ...$stamps to array $stamps = []

Rebased & ready again

Thank you @weaverryan.

🤞 fixed failing tests in fd4146c.

@weaverryan I want to have clear bus interface, that clear purpose is to send a message. This configuration shows what message is sent and how it should be treated. Implementing this will force my class to 2 things - create the message and send them. MessageBusInterface is made more robust due to that.
This loses abstraction that Messenger was to give to the application - I should not concern about how the message is sent, but if it correctly accepted by bus and eventually delivered.

"preoccupied with whether or not they could, they didn't stop to think if they should."

I think the original way was showing the better purpose of this functionality. Now is a blurred.
I'm interested, your opinion about design this interface in the context of abstraction.

Hi!

I don’t quite understand. We added an optional argument to the interface. Are you creating a class that implements this interface and the new argument causes you a problem? Or does the new optional argument cause an issue when you are using the interface?

Cheers!

if anything; we have 2 ways to do the same thing, as shown by the PR description. Not sure it's desired either 😕

currently messenger exposes a Stamp concept, which before was an implementation detail of the message.

As a vendor i might only care about "provide a message we can dispatch" (wether it's an envelope with stamps is a detail). But now the user might want to provide "a message" and "stamps", which as a vendor, i need to accept yes/no.

This is diversity happening :)

@weaverryan
@ro0NL described this very good. I'm not talking about a technical problem, but design philosophy.
I think, enriching MessageBusInterface interface with the Stamp concept unnecessary add more details.
In my opinion, this improvement makes less explicit MessageBusInterface interface. Choices like that make the project depend on Messenger less supportable.

That is my opinion. To keep more to KISS rule ;)

For Stamps we have:

we have 2 ways to do the same thing

And for the general message, we have 3 ways to send it with Stamp:

message

$bus->dispatch(
   new SendSmsNotification('Hi!')
);

message + array stamps

$bus->dispatch(
   new SendSmsNotification('Hi!'),
   [new DelayStamp(10), new QueueNameStamp('low')]
);

envelope + array stamps

$bus->dispatch(
   new Envelope(new SendSmsNotification('Hi!')),
   [new DelayStamp(10), new QueueNameStamp('low')]
);

envelope with stamps

$bus->dispatch(
   new Envelope(new SendSmsNotification('Hi!'))
       ->with(new DelayStamp(10), new QueueNameStamp('low'))
);

Envelope has always been part of the "dispatch" contracts. Since StampInterface is an integral part of Envelope, stamps have always been part of the "dispatch" contracts too.
If there should only be one way, it could be to remove passing an Envelope directly.
But that would only create more WTF to me (e.g. pass an envelope and have it be considered the message?) + unneeded BC break maybe?

the nice thing is Envelope extends object, so we can see any message as type object, not knowing about evenelops/stamps.

I've no real issue with the change. Personally i like dispatch(object $message): Envelope (one can discard the return value, considering it void), it's straightforward.

Comparing this to a real life scenario; can we pass a message/envelop and its stamps separate to a mail deliverer? Wouldnt they expect a stamped message/envelop instead?

Comparing this to a real life scenario; can we pass a message/envelop and its stamps separate to a mail deliverer? Wouldnt they expect a stamped message/envelop instead?

Ha! Indeed. But what I would personally really like is for the mail deliverer to come to my house, put the items in the envelope for me, close it, put the stamps on, then take it to the post office. That's a bit outside of the scope of what their job should be perhaps, but it would be awesome! Even in the real world scenario, there's a balance between purity and having a great customer experience (neither should dominate).

I really like your example, but I see this very straightforward.

For a simple message:

I would personally really like is for the mail deliverer to come to my house, put the items in the 
envelope for me, close it, put the stamps on, then take it to the post office.

you have:

$bus->dispatch(
   new SendSmsNotification('Hi!')
);

If you want advanced use, then you simply use Envelope with Stamp's.

This change simply provides something between that is neither of these solutions and don't give use real advantage - only more blurred interface:

I would personally really like is for the mail deliverer to come to my house, put the items in the 
envelope for me, close it, then *maybe I will inform him about my stamps and he can add his stamps on*, then take it to the post office.

@nicolas-grekas I always like Messenger not to be strict and enforce own Interface over message. Then any part of Envelope should be also added to this interface? Then why not add a third optional parameter, to act like Envelope function withoutAll? I think functionality/manage of Stamp's should be closed only in Envelope.

I simply want to keep it simple stupid:

• give us a message and we will deliver it,
• give us Envelope with extra data and we will deliver it as you wish.

the mail deliverer to come to my house, put the items in the envelope for me, close it, put the stamps on, then take it to the post office. That's a bit outside of the scope of what their job should be perhaps

exactly, it shows multiple concerns. Not an issue per se, but has its cost. In real life this is called Franking.

This also comes with a trust issue, some trust this to go right, others dont and stamp themselves. Hence i think this leads to diversity.

The question is; if we pass an "envelop/message" and "stamps" separate, can we assume it will be franked implicitly? Im not sure it's obvious.

Ultimately i believe a message should be stamped before it can be dispatched :/

Honestly, I lost track of what is discussed here.
If we're discussing variadic vs array as trailing argument, both are essentially the same and it's a matter of code style preference.

the "design philosophy" itself still :) (moving the stamping concern to the dispatching side)

it always has been on the dispatching side, so this is old :)

before we didnt stamp in dispatch() at least

-        $envelope = $message instanceof Envelope ? $message : new Envelope($message);
+        $envelope = Envelope::wrap($message, $stamps);

Semantically, this is strictly the same. There is a bijection between both styles:

$bus->dispatch($msg, $stamps);
vs
$bus->dispatch(new Envelope($msg, $stamps));

I see why the 1st style has been added. There is no technical reason not to do it.

@nicolas-grekas
I simply wanted to show that the author took the direction that in my opinion, give more bad that good outcome.

If you insist that they are the only use cases, then that you are correct. This would be correct. The original:

$bus->dispatch($msg);

and

$bus->dispatch(new Envelope($msg, $stamps));

Semantically, this is strictly the not same. This led to ignoring the first use case. As mentioned here, I gave you my arguments. Is there any argument, that could convince you? Maybe, but not mine. If my arguments didn't convince you, my job here is done.