Andrus Adamchik wrote:
> Well, aside from my original question, current implementation of
> EventSubject will *always* require a reference to the subject instance
Yes, that was the intention (I think you meant EventManager?)
> (e.g. as public static final EventSubject XYZ), since EventSubject
> doesn't implement hashCode() and/or equals() method. So essentially,
> creating a subject for the same owner and name twice, will produce two
> different subjects (at least from the point of view of EventManager). I
> don't think this was intended like that?
I just didn't need them yet (that's why I put the existing subjects into
the static references for now), but I fully agree they should be
implemented nevertheless for correctness' sake. In order to really finish
this a weak registry map of subjects is the right solution so that people
can call EventSubject.getSubject() repeatedly and get the correct one, and
the public static reference can be used for convenience, as it is now.
Btw, I just saw that the subject's internal name already contains the
owner name, in the form com.myapp.OwnerClass.SubjectName; for clarity this
should probably be changed to ..OwnerClass/SubjectName to better separate
what's what.
Another thought, while we're at it - if you have better ideas for the
'owner' (like say any Object?) I'm open for that; using a Class just
seemed obvious to me at the time, for namespace and uniqueness reasons.
> So maybe just switch back to Strings?
Please noo.. :-(
Using plain Strings really impacts flexibility for backwards-compatible
future expansion, subclassing, interface adoption, polymorphism and
practically any other patterns that might be used to solve upcoming
problems. It's bad enough that we have to use scalar wrappers; please
let's use real objects whenever we can.
Feel free to add any methods that you need for now or let me do it next
week (Monday most likely); I'm off for the weekend now.
Holger
This archive was generated by hypermail 2.0.0 : Sat Jun 28 2003 - 05:05:48 EDT