[Messenger] Introduce SelfStampableInterface

[VincentLanglet]

Q	A
Branch?	7.1
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues	Fix #...
License	MIT

Idea was kinda suggested from #54141 (comment)
This interface would allow to define stamp I always want by default with a message.

By merging in the order

array_merge($message->getStamps(), $stamps);

I can still override a stamp when dispatching the message.

[derrabus]

An alternative idea, also suggested by the comment that you've linked, was to use attributes for stamps. Can you elaborate why you dismissed that idea in favor of an interface?

[VincentLanglet]

An alternative idea, also suggested by the comment that you've linked, was to use attributes for stamps. Can you elaborate why you dismissed that idea in favor of an interface?

I misunderstood/forgot about the comment when working on this and the only idea I had in mind was an interface.

Then, I reread the comment and even found #50812
but I'm not sure what would be the interest of attributes here.

IMHO the interface is simpler:

• A feature with #[DelayStamp(123)] would require to declare every stamps as attributes, you cannot use this for other libs if they don't declare their stamps as attribute.
• A feature #[AutoStamp(new DelayStamp(123))] solve the previous issue but It still require extra manipulation with ReflectionClass when the instanceof SelfStampableInterface and a getter does all the job.

Also, dynamic stamps would be impossible with attribute.

This would be useful for the LockStamp in #54141,
you could have

class Message implements SelfStampableInterface
{
     public function __construct(private int $projectId) {}

     // With this stamp, I ensure there is never 2 messages for the same Id in the queue
     public function getStamps(): array {
         return [new LockStamp(self::class . $this->projectId)];
     }
}

[ro0NL]

i tend to prefer stamps as attributes for the sake of decoupling

having runtime flexibility is nice, but IMHO it needs to be scalable, eg. we might want to use additional services to compute a stamp

in that sense, middleware layer already brings full runtime flexibility in userland to apply default stamps

for compiling stamps as-a-service from attributes, take this:

$stampServiceDef = new Definition($attr->getName(), $attr->getArguments());

[VincentLanglet]

i tend to prefer stamps as attributes for the sake of decoupling

having runtime flexibility is nice, but IMHO it needs to be scalable, eg. we might want to use additional services to compute a stamp

in that sense, middleware layer already brings full runtime flexibility in userland to apply default stamps

for compiling stamps as-a-service from attributes, take this:

$stampServiceDef = new Definition($attr->getName(), $attr->getArguments());

Sorry, I don't understand how will be solved, in the simple way, the

class Message implements SelfStampableInterface
{
     public function __construct(private int $projectId) {}

     // With this stamp, I ensure there is never 2 messages for the same Id in the queue
     public function getStamps(): array {
         return [new LockStamp(self::class . $this->projectId)];
     }
}

situation with

#[LockStamp()] // Error missing first param.
class Message implements SelfStampableInterface
{
     public function __construct(private int $projectId) {}
}

[ro0NL]

perhaps self-stamping is the way to go for such simple runtime usecases

no strong opinion :)

#[LockStamp()]

it could compute a key from the message payload by default

[VincentLanglet]

perhaps self-stamping is the way to go for such simple runtime usecases

no strong opinion :)

#[LockStamp()]

it could compute a key from the message payload by default

With a method, you also can add the stamp conditionnaly

public function getStamps(): array {
         return $this->foo ? [new FooStamp()] : [new BarStamp()];
     }

@derrabus do you have time for a new look ? :)