Minimize Different Methods

"How we made GemStone work on both Smalltalk/DB (ST/DB) and VisualWorks (VW) implementations of the SmalltalkLanguage."

GemStone is described as an active, object-oriented database management system.

Objects, including behavior, rather than just structs are stored in the repository. It is described as active because the developer has the option of executing the behavior on the server (a.k.a., the stone) as an alternative to executing the behavior in the client application.

Smalltalk/DB (ST/DB) is the dialect of Smalltalk used as the implementation language for the code on the stone.

For the most part ST/DB and VisualWorks (VW) are syntactically and semantically equivalent. The differences that do occur require a developer to either adjust the implementation to avoid differences, or to manage the differences. Our goals are to:

MinimizeDifferentMethods
ManageDifferencesConsistently?

(These patterns are based on GemStone 4.1.3 and VisualWorks 2.0.)

1. Add Redundant Selectors In ST/DB: Some of the ST/DB classes which map to VW classes are semantically similar, but use different selectors to implement the same behavior. The redundant selectors are added in ST/DB because developers tend to be more familiar with the VW selectors.

Example: The ST/DB Dictionary method for enumerating over its associations is #doAssociations:. We add the following method: associationsDo: aBlock ^self doAssociations: aBlock

2. Add Redundant Selectors in VW: Methods in ST/DB and VW may have the same selector, but have different semantics. When ST/DB implements the same semantics using a different selector, extend the VW class to include the ST/DB selector.

 Example: In ST/DB Collections, the includes: method uses an identity-based comparison, 
  whereas in VW, the comparison is value-based.  ST/DB uses the includesValue: method for value-based comparisons.  
  We implement #includesValue: in VW; #includes: is now considered part of the private interface.
    includesValue: anObject
    ^self includes: anObject

3. ReFactor to Isolate Code Differences to a Small Method: Sometimes there is no way to unify the code by simple programming practices. For example, VW has separate Date and Time classes, while ST/DB has a single DateTime class. We use an Adapter class to buffer the differences. Still, careful factoring of behavior can ease the maintenance of the Adapter class itself.

 Example: A recent review of the printing protocol of the GTDateTime class reveals the following methods, 
  and the result of sending the method to GTDateTime now in VW
asStandardString8/13/96
displayString13 August 1996
printOn: aStreamAugust 13, 1996
printFormattedAugust 13, 1996 5:40:41 pm 

  Except for #asStandardString, the above methods are implemented using a  
  reference to the underlying class (i. e. Date in VW).  
   #asStandardString uses a private method, 
   #printFormat:,which converts the GTDateTime to aDate and forwards the 
   #printFormat: to it.

If we reimplement the other three methods to use #printFormat:, all of the "adapting code" which requires a different implementation is in one method.

CategoryComparisons