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

[John D. Ament]

I don't think this is something we can state outright.  If I
BeanManager.fireEvent("some string"); then it's not mutable.

On Thu, Dec 18, 2014 at 3:03 AM, Jozef Hartinger <jharting at redhat.com>
wrote:
>
>
> 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 listcdi-dev at lists.jboss.orghttps://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.
>
>
>
> _______________________________________________
> 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/8c3e8a83/attachment.html