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?

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 withReflectionClass when theinstanceof 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)];     }}

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 Messageimplements SelfStampableInterface{publicfunction__construct(privateint$projectId) {}// With this stamp, I ensure there is never 2 messages for the same Id in the queuepublicfunctiongetStamps():array {return [newLockStamp(self::class .$this->projectId)];     }}

situation with

#[LockStamp()]// Error missing first param.class Messageimplements SelfStampableInterface{publicfunction__construct(privateint$projectId) {}}

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 ? :)

Maybe you have some time for a review@nicolas-grekas ?

Friendly ping@derrabus ; would you have time for a review ?

Unfortunately not at the moment. 😞

Looking at this after some time has passed make me think that stamps could simply be attributes on classes, and this would actually make this feature real. All it need it that all stamps extend\Attribute and some outer middleware exist in the dispatcher to expand those as stamps.

Except maybe that it wouldn't allow dynamism in stamp data, do you have any real life use case for such dynamism?

Stamps themselves should not be attributes, as they are metadata about a particular message, not about the class. For instance, there are some stamps that are added based on how the message is dispatched or how it is read from the queue.

@ro0NL for applying automatic stamps on messages using a given class, I'd rather have aAutoStamp attribute (name to be bikeshed) taking a Stamp as argument (allowing to repeat the attribute) than making stamps themselves as attributes while stamps themselves cannot always be attributes. It would reduce confusion IMO.

Except maybe that it wouldn't allow dynamism in stamp data, do you have any real life use case for such dynamism?

This is a big loss for me. I have some stamp like "DeduplicateStamp" or "DelayStamp" which are added by default (because used 99% of the time) but I need the ability to skip them sometimes. I have also stamp which are added based on the size of the data.

This PR doesn't forbid stamp as attribute, it can still be done in another PR by someone else.

stampscould be attributes, if the metadata is constant. Otherwise dont apply the stamp as an attribute on your message.

Definitely agree, stamps are basically no more no less than very simple DTOs, exactly what attributes also are in the end.

Whereas@stof is right about the fact thatsome stamps shouldn't be, my opinion is that those which can should directly be attributes. There's no need add an indirection layer here: the most direct implementation would also be the most readable in the end.

This is a big loss for me. I have some stamp like "DeduplicateStamp" or "DelayStamp" which are added by default (because used 99% of the time) but I need the ability to skip them sometimes. I have also stamp which are added based on the size of the data.

OK, I'll stop talking now about attributes, this is not what the issue is about, thanks for answering.

Hi@derrabus@ro0NL@stof

It's unclear to me how to move this forward.
Stamp as attribute is a nice feature but should be done in another PR as it's unrealted.
Therefor I don't think there is a current request change here ; it might just require your review then ?

Hi@ro0NL@derrabus I rework the PR to use a middleware, if you want to review again.

Also I wonder if you have a better name in minde thanSelfStampableInterface andAdd SelfStampableStampMiddleware.

This would simplify a lot when using DeduplicateStamp with same message in many places

This would simplify a lot when using DeduplicateStamp with same message in many places

That's the reason I implemented both ;)

I might be wrong but it seems like failure is unrelated so@derrabus@ro0NL@stof it's ready to be reviewed.

Friendly ping@OskarStark@nicolas-grekas if you wanna review