This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that's appropriate (perhaps in mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override createHM() I
can provide a custom implementation, or wrap the normal one, without having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
