On Wed, 2009-05-27 at 14:07 -0700, Gavin King wrote:
On Wed, May 27, 2009 at 1:47 PM, Clint Popetz
<cpopetz(a)gmail.com> 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.
I thought the TypeLiteral/Class/Type was to identify the event type that
the observer is interested in. Like you said, the type variable does us
no good; however, we have to know somehow for an event type T that some
registered Observer<?> is interested in that event.
So where do we get T now that the signature has changed to not include
it?
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>.
Seems a little confusing. Observer<Bar> would always see events of type
Foo anyhow with the current semantics in the RI (did it change in the
spec?).
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);