[cdi-dev] Is the concept of mutable event payload specified

[Romain Manni-Bucau]

Not sure I follow completely your last point: you would like to add a
locking mecanism in CDI?

I think keeping it simple and as in plain java would be the best for a
first release (2.0)

You can still rely on @Singleton (ejb) for locking and surely on
something in concurrency utilities

wdyt?


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-12-17 17:49 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:
> Ok guys,
>
> Let’s do it again. I didn’t say we have to forbid the mutability I said we
> have at least to explicitly write that it’s mutable and seriously think of
> having it immutable for event fired asynchronously.
>
> (Pete) I don’t think it’s specified. As objects are, by default in Java,
> mutable, I would assume that payloads are implicitly mutable.
>
>
> Sorry @Pete I don’t agree with your point. Yes, in Java object are mutable
> but firing an event is not a standard Java feature : you send your object to
> a black box and let this box dispatch your object to listeners transforming
> one call to multiple call : it’s far from standard Java rules. Even if it’s
> not written it’s an observer pattern and there are people out there thinking
> that introducing mutability in observer is an anti-pattern since some
> listener will receive a different payload than the one that was sent to
> them.
> It’s like making a method call and having no guarantee that the parameter
> received in the callee has the same value that in the caller...
> I won’t start discussion on bad practice or anti pattern  as I also use
> mutability in event but there as much reason for user to assume their
> payload will be mutable than the other way around.
> I can assure you that when I give a talk on CDI, this payload mutability is
> often a surprise for attendees...
>
> (Romain) why isn't it portable?
>
>
> So yes @Romain it’s not portable (in theory of course, since both
> implementations support mutability). Someone could write a CDI
> implementation with event payload immutability without any issue with the
> spec and TCK.
>
> Most of you are so dependent of this feature that you only reacted to the
> idea or forbidding it (which wasn’t the content of my mail) ;). So we all
> agree that it’s an important feature. Therefore what’s the issue to specify
> this mutability and add TCK test for it ?
>
> Now I don’t deal with that subject for nothing, we are planning to introduce
> Async events. I think that it’ll bring extra complexity if we support
> mutability in async events. And even if I’m wrong and we finally go for
> mutability in async events, this will lead to possible side effect (lock)
> that could have impact on perf, so it should be explicitly written IMO.
>
> Antoine
>
>
>
>
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.