Re: [hibernate-dev] SynchronizationRegistry: expose read (lookup) operations?
On 25 October 2017 at 16:22, Steve Ebersole <steve(a)hibernate.org> wrote:
> Yes that would work for me, but thinking about the implementation it
> implies you'd need to hold on to both a Set and a Map, and then we'd
> be exposed to silly usage like people adding the same synchronization
> twice in two different ways?
Does it? Nothing in the SPI requires us to store things in any specific
way. E.g. we can keep just a Map - when we are passed a
KeyableSynchronization we'd use that key, when we are passed a
non-KeyableSynchronization Synchronization we'd generate one ourselves.
Sure it's possible but it introduces complexity; considering this is
an SPI I'd assume we can just enforce a different contract and keep it
simple.
And we cant stop people from every conceivable "silly usage". At some point
we are professional developers and should be able to do the non-silly things
;)
And as far as your "register the thing twice" worry... rhetorically, what
stops them from calling:
reg.register( "abc", MySync.INSTANCE )
reg.register( "123", MySync.INSTANCE )
Nothing.
No doubt, but also if I write such code it's self-explanatory what I get.
Some less trivial example gets me in undefined places:
reg.register( "abc", MySync.INSTANCE )
Synchronization instance = reg.get("abc");
reg.register(instance);
quiz:
- will my Syncrhonization instance get all notifications twice?
Just thinking that it would be better to avoid undefined expectations.
Are you aiming at backwards compatibility?
In that case I'm happy to explore non-breaking alternatives, I was
merely assuming that SPIs would be wildfly different anyway so no big
deal in breaking one more.
Thanks,
Sanne
> I'd rather expose a single consistent way: having to make up an id
> doesn't seem too inconvenient considering it's an SPI.
Well, again, I don't see how KeyableSynchronization is a "inconsistent"
approach. In fact out of the 2, it is my preferance.