The hush library is meant to give flexible access to a window programming toolkit and possibly multiple embedded interpreters etcetera. How generic can you become and what is the price you, as a programmer, have to pay for that. in developing hush, we encountered a number of problems and dilemmas, as listed below. One of the recurrent problems, of course, is what is to be considered a basic class/concept and what is merely a derivative of some (already) existing basic class.

   event dispatching -- implicit or explicit
   garbage collection -- ...
   remote kit -- communication protocol / security
   multiple kits -- safe, java 
   multiple widget sets -- how to select
   compound widgets -- component management/configuration
   handler names -- sufficient for command binding?
  

   client (X) -- to get access to (remote) information
   protocol (XX) -- defines the protocol of interaction with clients
  
   thread (X) -- to allow for multithreading
  

The hush library is organized around a limited number of (semi) abstract interface classes and is realized in a corresponding set of implementation classes employing the handle body idiom, virtual self reference and dynamic role switching. The average user however needs to have NO knowledge of any of these techniques. Only a limited number of the subclasses mentioned below are exported. We currently have a discussion whether to export the event subclass hierarchy to export special wrapper classes reflecting the structure of the event hierarchy. The exported classes are indicated with a *, special wrapper classes with a +. Classes decorated with a ? are not or only partially realized. The annotation [kit] indicates the possibility of dynamic role switching, that is the possibility to change the modality of the kit dynamically, for example to choose a different embedded interpreter. The annotation {widget} indicates the possibility of virtual self reference. However in contrast with the kit, a widget cannot change its modality dynamically, that is the widget modality is determined at startup time (by the session) and cannot be changed afterwards.

   session* -- tcl_session, python_session?
   [kit]* -- tcl_kit, python_kit?, perl_kit?, dlp_kit?, java_kit??
   handler* -- widget*, item* (and event, action, kit, session, client ?)
   event* -- tcl_event+, file_event+, url_event?, tt_event? 
   binding* -- tcl_binding, dlp_binding?
  
   {widget}* -- tk_widget, meta_widget?, motif_widget?
   item* -- canvas_item, text_item?
  
   client* (X) -- net_client, file_client,  (?? url_client ipv net?)
   protocol& (XX) --  ??
  
   thread (X) -- ?? 
  
  

Every class in hush is derived from the handler class to allow for access via a script language. However this dominant role of handler may change in the near future.

There are still a number of elements in hush undocumented, such as:

This item discusses how to realize the class event.

Problem: Simply put the dilemma is whether to have a slim event class and subsequently derived event classes which allows for explicit dispatching on event types and compiler support for operations on events, or a fat event class which necesitates dynamic testing but allows for a general (implicit) dispaqcth procedure.

Background: Discuss pro's and con's.

• Explicit dispatching This is needed especially in the case a handler is written for multiple event classes.

Pro: compiler support for event operations, named meber function to deal with different events

Con: May need casts when used in implici mode, proliferation of handler methods

• Implicit dispatching The assumption here is that basically a handler is written for one kind of event.

Pro: Uniform event handling, allows for arbitrary user extensions, easily documented (at the price of an occasional lie).

Con: need for dynamic checking, need for dispatching on explicit eventclass tag.

Problem: Memory leaks, resource management

Background: C++ has no garbage collection, developers are lazy.

Solution: Support for resource management

Realization: The _register function.

Discussion: Is it waterproof?

Problem: We need to integrate multiple embedded interpreters, possibly remote. However, multiple kits may cause instability. See papers/patterns.

Background: Hush supports multiple interpreters. In principle we solve this by eiter role switching or slave interpreters.

Solution:

• The default kit When the kit is given a value in the constructor of the session-derived application class, this will be the global (default) interpreter.
• Changing kits The user has to create either a new kit, or do role switching. However, because of the instability problem, role-switching is allowed for slave (second level) interpreters only.

Realization: Handle/body, dynamic role switching

Problem:

Background:

Solution:

Realization:

Discussion: