<div dir="ltr">I don't think this is something we can state outright. If I BeanManager.fireEvent("some string"); then it's not mutable.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 18, 2014 at 3:03 AM, Jozef Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<br>
<div>On 12/17/2014 05:49 PM, Antoine
Sabot-Durand wrote:<br>
</div>
<blockquote type="cite">
<div>Ok guys,</div>
<div><br>
</div>
<div>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</div>
</blockquote></span>
Agreed.<span class=""><br>
<blockquote type="cite">
<div> and seriously think of having it immutable for
event fired asynchronously.</div>
</blockquote></span>
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.<br>
<blockquote type="cite"><div><div class="h5">
<div><br>
</div>
<div>
<blockquote type="cite">(Pete) I don’t think it’s
specified. As objects are, by default in Java, mutable, I
would assume that payloads are implicitly mutable.</blockquote>
</div>
<div><br>
</div>
<div>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. </div>
<div>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...</div>
<div>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.</div>
<div>I can assure you that when I give a talk on CDI,
this payload mutability is often a surprise for attendees...</div>
<div><br>
</div>
<div>
<blockquote type="cite"><span style="font-family:Menlo-Regular;font-size:11px">(Romain) why isn't
it portable?</span></blockquote>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 ?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Antoine</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=""><pre>_______________________________________________
cdi-dev mailing list
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</pre>
</span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></blockquote></div></div>