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

Jozef Hartinger jharting at redhat.com
Thu Dec 18 03:03:01 EST 2014


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 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/43674926/attachment-0001.html 


More information about the cdi-dev mailing list