Hi, The spec defines BeanManager.removeObserver to have a wildcard type: public void removeObserver(Observer<?> observer); and says "The container must stop sending event notifications to the deregistered observer."  Does that sentence, taken with the wildcard type, imply that the observer should be removed for all events for which it is registered?  Currently ManagerImpl implements storage of observers as a map from EventType -> Observer, which means removal of an observer without knowing its event type would be linear in # observers, unless I change the implementation. Thanks, -Clint -- Clint Popetz http://42lines.net Scalable Web Application Development _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

Now that I'm thinking about it, I wrote "the observer should be removed for all events for which it is registered" but because addObserver() is typed to Observer<T>, and because you can't implement the same interface twice (even with different parameterizations) any given instance can only be registered once. Well, it could be registered more than once, but the implementation (and possibly the spec) could prohibit that, because it's meaningless. In that case, I have no problem with the semantics of removeObserver. But the <?> means I'd have to rewrite a lot of observer storage/lookup code, and it's not symmetric with addObserver(), so I wonder what the advantage of the wildcard is. -Clint On Wed, May 27, 2009 at 2:35 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > yes, that's what it means, though I must admit that when I made that > change it was not totally clear to me that it was the right thing to > do :-/ > > Probably needs a bit more discussion... > > On Wed, May 27, 2009 at 11:59 AM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: > > Hi, > > > > The spec defines BeanManager.removeObserver to have a wildcard type: > > > > public void removeObserver(Observer<?> observer); > > > > and says "The container must stop sending event notifications to the > > deregistered observer." Does that sentence, taken with the wildcard > type, > > imply that the observer should be removed for all events for which it is > > registered? Currently ManagerImpl implements storage of observers as a > map > > from EventType -> Observer, which means removal of an observer without > > knowing its event type would be linear in # observers, unless I change > the > > implementation. > > > > Thanks, > > -Clint > > > > > > -- > > Clint Popetz > > http://42lines.net > > Scalable Web Application Development > > > > _______________________________________________ > > webbeans-dev mailing list > > webbeans-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/webbeans-dev > > > > > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- Clint Popetz http://42lines.net Scalable Web Application Development

well, (1) an Observer could be registered multiple times with diff event bindings

at runtime

You can't do T.class in Java :-)

On Wed, May 27, 2009 at 1:06 PM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: > Now that I'm thinking about it, I wrote "the observer should be removed for > all events for which it is registered" but because addObserver() is typed to > Observer<T>, and because you can't implement the same interface twice (even > with different parameterizations) any given instance can only be registered > once. Well, it could be registered more than once, but the implementation > (and possibly the spec) could prohibit that, because it's meaningless. > > In that case, I have no problem with the semantics of removeObserver. But > the <?> means I'd have to rewrite a lot of observer storage/lookup code, and > it's not symmetric with addObserver(), so I wonder what the advantage of the > wildcard is. > > -Clint > > > On Wed, May 27, 2009 at 2:35 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: >> >> yes, that's what it means, though I must admit that when I made that >> change it was not totally clear to me that it was the right thing to >> do :-/ >> >> Probably needs a bit more discussion... >> >> On Wed, May 27, 2009 at 11:59 AM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: >> > Hi, >> > >> > The spec defines BeanManager.removeObserver to have a wildcard type: >> > >> > public void removeObserver(Observer<?> observer); >> > >> > and says "The container must stop sending event notifications to the >> > deregistered observer." Does that sentence, taken with the wildcard >> > type, >> > imply that the observer should be removed for all events for which it is >> > registered? Currently ManagerImpl implements storage of observers as a >> > map >> > from EventType -> Observer, which means removal of an observer without >> > knowing its event type would be linear in # observers, unless I change >> > the >> > implementation. >> > >> > Thanks, >> > -Clint >> > >> > >> > -- >> > Clint Popetz >> > http://42lines.net >> > Scalable Web Application Development >> > >> > _______________________________________________ >> > webbeans-dev mailing list >> > webbeans-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/webbeans-dev >> > >> > >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org > > > > -- > Clint Popetz > http://42lines.net > Scalable Web Application Development > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

So if an observer can be added for an event with different bindings, why shouldn't it be possible to remove it from observing the event with a specific binding?   I presume that's what Event.resumeObserver() does, i.e. removes that observer for the Event's bindings.  It seems reasonable to want to do that independent of whether you have an event, through the BeanManager.

On Wed, May 27, 2009 at 1:47 PM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: >> (2) adding a type variable doesn't help you, since it just gets erased >> at runtime >> >> You can't do T.class in Java :-) > > Good point. Is the parameterization of addObserver just to ensure that > Observer<T> is registered for Class<T>? yes, exactly. So now I'm wondering (again) whether the TypeLiteral/Class/Type on addObserver() is really adding any value here.

It is there to accommodate two cases: (1) where the event type that you are registering an observer for is a type variable, in which case you could potentially have a Class<T> or a TypeLiteral<T>, which hold an actual value for T at runtime, but an Observer<T> which is generic and does not. (2) If Foo extends Bar, I was thinking that you could register an Observer<Bar> for an event of type Foo. However, I now notice that the type declarations don't actually support that (though this could by fixed easily). I don't think (2) is a very important case, since it is trivial to wrap Observer<Bar> in Observer<Foo>.

Case (1) is a little more subtle, but it seems like I can't really think of a real usecase for it. I think we could reasonably have a single addObserver() method as follows: public <T> void addObserver(Observer<T> observer, Annotation... bindings);

On Thu, May 28, 2009 at 2:14 AM, David Allen <drallendc(a)gmail.com&gt; wrote: > So where do we get T now that the signature has changed to not include > it? do Observer.getClass().

On Thu, May 28, 2009 at 10:37 AM, David Allen <drallendc(a)gmail.com&gt; wrote: > On Thu, 2009-05-28 at 10:18 -0700, Gavin King wrote: >> On Thu, May 28, 2009 at 2:14 AM, David Allen <drallendc(a)gmail.com&gt; wrote: >> >> > So where do we get T now that the signature has changed to not include >> > it? >> >> do Observer.getClass(). > > That would be the class Observer. But how do we know what the type of > the event is? In other words, it would have been the actual type used > with Observer<T> instead of the parameter T. However, due to erasure, > that information will not be available inside the addObserver() method. observer.getClass().getGenericInterfaces() iterate to find observer, cast to ParameterizedType, call getActualTypeArguments().