CampSmalltalk: Portable code style

I want people to be aware of the various coding styles for making code both portable and maintainable. In essence, I'd like to encourage people to build a portability layer into their model instead of subclassing their model for specific dialects. I'm sure this is obvious for most; however I have seen code that attempts to achieve portability by subclassing the model:

XyzModelClass
  XyzModelClassVA
  XyzModelClassVW

If you use subclasses for portability, as shown above, then it is difficult to use subclasses for specialization for other purposes. If some other user of the "XyzModelClass" needs to subclass for some special purpose, then that user must subclass many classes instead of just one:

XyzModelClass
  XyzModelClassVA
    AbcSpecialModelClassVA
  XyzModelClassVW
    AbcSpecialModelClassVW

One way to achieve portability without model subclassing is to write the code in some "general" way, and then adapt the various environments (Smalltalk dialects) to that general way:

XyzModelClass
  AbcSpecialModelClass

GeneralSupport (application that extends multiple classes)
  GeneralSupportVA (application that extends multiple classes)
  GeneralSupportVW (application that extends multiple classes)

The "general support" layer (GSL) is in essence what the ANSI Smalltalk standard is. If your code conforms to that standard, then it is a matter of bringing the image into conformance with that standard.

Coding for a GSL is fine so long as that layer exists and fills all your needs for portability. If a standard layer doesn't exist or isn't adequate for your needs then there is a need for a new layer--that I hope you will develop and share with everyone.

The problem is, what do you do until a GSL exists and is adequately supported? The solution I've found quite useful is to create a temporary general support layer (TGSL) to route messages through for handling in a portable way.

XyzModelClass
  AbcSpecialModelClass

XyzPortal (a global)

XyzPortableBehaviorClass
  XyzPortableBehaviorClassVA
  XyzPortableBehaviorClassVW

XyzPortal is a global that holds an instance of the correct subclass of XyzPortableBehaviorClass. XyzModelClass is written to depend on XyzPortal to handle messages that instances of XyzPortableBehaviorClass understand.

Both the GSL and the TGSL are certainly perferable to subclassing the model for portability. The general support layer is preferable to the TGSL; however, it may not be possible to use if that layer doesn't exist, isn't complete, or isn't sufficient. Some code may have to be written today with a TGSL--in the hopes that a general support layer can be used in the future.

Why create a TGSL to route messages through instead of just extending classes to support a new GSL? The biggest reason is ease of maintenance. You don't have method collisions with similar extensions by other projects. You can often modify code for multiple dialects from a single code base. You don't have to extend classes with prefixed selectors. You know precisely what less-portable code your application depends on.

In short, I've found the TGSL technique to be very useful for a couple projects I've worked on. Code based on a TGSL is very easy to port and maintain where it is impossible to write code to conform to some general standard.