AbstractWidgetBridge sounds fine. I was also thinking if we should get rid of the "Bridge" postfix, as they are already in the "bridges" package.
setupPeer() also sounds fine to me. James Margaris -----Original Message----- From: Michael Turyn [mailto:[EMAIL PROTECTED] Sent: Monday, September 11, 2006 11:36 AM To: [email protected] Subject: Bridge abstract superclass Importance: Low "Right governance begins with the proper naming of things," ---K'ung fu-tzu I named AbstractBlackBoxWidgetBridge that way because 1.) It was to be a powerful but abstract superclass 2.) ...for widget bridges... 3.) ...which was to be free of direct method call on the widgets---I had had a lot of trouble adapting Dojo bridges to the extant bridges code because the latter embodied assumptions about methods on the widget peers---I wanted to create something that other bridges could refer to without needing the know anything about the peer, hence the "Black Box". Accurate, but ungainly; anyone have a better choice, or think the current one's good enough? I'd vote for "AbstractWidgetBridge". Also: the method that formerly always created a peer, "createPeer", now doesn't always do so---for example it often calls "obtainPeer" which either creates a new peer (the Dojo widget bridges) or resolves an extant one (e.g., an HTML dom node, or the as-yet unchecked-in ExternalWidgetBridge). I'd like to rename it to something like "setupPeer". Any opinions?
