What about addingAbstractUid::getDateTime(): ?DateTimeImmutable instead?

What about addingAbstractUid::getDateTime(): ?DateTimeImmutable instead?

Potentially, though personally it would feel like an anti-pattern to me as the behaviour is specific to only certain implementations.

I'm not a fan of interfaces on value objects personally. I would prefer a new method on the abstract class because it keeps things simple, and it doesn't force any extra logic on consumers. Actually, nullable return values are easier to deal with thanks to nullsafe operators.

I like the interface, I must admit. It plays nicer with static analysis than a nullable type. We might want to find a better name though.TimeBasedUidInterface?

AbstractTimedUid extends AbstractUid?

AbstractTimedUid extends AbstractUid?

Well, won't work since classUuid already extendsAbstractUid and not all UUIDs are time-based.

TimeBasedUidInterface is the correct name since we already haveTimeBasedUuidFactory.

One more thing: we might want to declareTimeBasedUuidFactory::create() as returningUuid&TimeBasedUidInterface

@nicolas-grekas is psalm failing on the intersection forTimeBasedUuidFactory::create()?

Looks like so 🤷
We're going to ignore it then.

Thank you@shrikeh.