Maybe it's a stupid idea, but are there arguments against using stamps as attributes directly?

#[AutoStamp(new DelayStamp(123))]
#[AutoStamp([new ValidationStamp(['Default', 'Extra'])])]
class AutoStampedMessage
{
}

Vs.

#[DelayStamp(123)]
#[ValidationStamp(['Default', 'Extra'])]
class AutoStampedMessage
{
}

It's done, i'm not sure about second commit
Should we really tag all stamps as class attributes ? Are they really all repeatable ?

Maybe it's a stupid idea, but are there arguments against using stamps as attributes directly?

I think I'm in favor of @derrabus' idea. This allows 3rd party stamps that aren't attributes to be used.

Interesting. Thank you for this PR.

Maybe it's a stupid idea, but are there arguments against using stamps as attributes directly?

It is the dispatcher that is smart, it knows how long a message should be delayed. It should not be the receiver nor the message itself.

If we add this kind of configuration on the message, how do a dispatcher opt out? Or how can a dispatcher change the config, Say delay for 10s instead of 5s? (think retry middleware).

I think we open a can of worms.. What is the reason for adding auto-stamps or adding stamps to the message directly?
If it is only syntax sugar, then I would prefer keep it explicit as we do now.

It is the dispatcher that is smart, it knows how long a message should be delayed.

No, the dispatcher should stay dumb. Adding stamps based on attributes (however those might look like) can and should be done by a middleware.

Or how can a dispatcher change the config, Say delay for 10s instead of 5s? (think retry middleware).

The sttributes on the message should be a default. The retry middleware needs be able to override those defaults.

What is the reason for adding auto-stamps or adding stamps to the message directly? If it is only syntax sugar, then I would prefer keep it explicit as we do now.

Yes, it is syntactic sugar for wiring a piece of middleware that always adds the same stamps to a specific message class.

I see it like defaults too.
Maybe the middleware should be smarter and read other stamps to apply attributes stamps on the envelope ?

With the current implementation, if I write

$bus->dispatch(new MyMessage(), [new DelayStamp(5)]);

and the MyMessage has a DelayStamp attribute ;
wouldn't the new DelayStamp(5) overridden by the attribute of the message in the middleware ?

I would expect the opposite, the attribute should be a "default" but can be overriden when dispatching the message.

I just thought/wanted a similar feature and tried to introduce a SelfStampableInterface in
#54366 dunno if it's a better/simpler solution ?

Thank you @KerianMM for your contribution and the effort you put into this PR! We're closing this due to lack of recent activity. If this feature is still needed, please feel free to open a new PR against the current branch.