On 12/17/2014 05:49 PM, Antoine Sabot-Durand wrote:
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
Agreed.
and seriously think of having it immutable for event fired
asynchronously.
I agree that we should have a discussion about pros/cons. From what
I
saw working on a fireAsync prototype to me the possible benefits of
allowing immutable events only are not worth the limitations.
> (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(a)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.