Easing compatibility with Grease

Photo by DarkSide, sxc.hu

In December, I gave a presentation on portability to the NYC Smalltalk group. Seaside now runs on at least seven different Smalltalk distributions. Given the lack of standardization, this is no minor feat; for Seaside’s developers, the need to keep code portable is always on our mind. As a result, we have gradually accumulated a set of tools, patterns, and conventions to help keep our code as portable as possible and to factor out code that needs to be implemented differently on each platform.

In our work on other projects, we found the same portability challenges came up over and over and we wanted to use the tools we had developed for Seaside to address them. So we began to split out the Seaside-specific functionality, allowing us to leverage the generic parts it in our other work. And thus Grease was born.

So what exactly is Grease?

• Grease enhances the ANSI Smalltalk standard. With only a few exceptions, we assume platforms are fully ANSI-compliant. Platforms want to support Seaside and standardization makes this easier for the project’s developers and its porters.
• Grease defines expected APIs with unit tests. Platforms can quickly determine if they are compatible and users can examine the tests to determine exactly which behaviours they can count on.
• Grease takes a pragmatic approach to compatibility. Sometimes a method behaves so differently on two platforms, for example, that we are forced to avoid it or to standardize on a new selector. To get standard exception signaling on all platforms, Grease is forced to provide special exception classes that can be subclassed. Sometimes we need to put “right” aside and settle, instead, on a solution that can be implemented everywhere.
• Grease tries to be concise and consistent. Despite its pragmatic approach, we still want to be “right” as much as possible. Because it’s hard to remove functionality once it has been added, we need to carefully consider each addition before proceeding. We’re moving slowly and looking for methods that are commonly used and that have clear names and semantics.
• Grease does not try to solve all problems. We are not testing Sockets or HTTP clients. We don’t expect platforms to have standard SSL or graphics libraries. Its scope may grow over time, but for now we’re focusing on extending the functionality of the core classes defined in the ANSI standard (collections, exceptions, streams, blocks, etc.) and on other pieces of functionality that are critical to the Seaside project (e.g. random number generation and secure hashing).
• Grease is widely adopted. Implementations exist already for all platforms that support Seaside 3.0. As well as Seaside, new versions of Magritte, Pier, and Monticello are already being implemented on top of Grease.

If you’re developing on Squeak or Pharo, you can also benefit from Slime, which uses the Refactoring Browser to find and, in some cases, rewrite common compatibility problems. Think of Grease as defining what you can write and Slime as defining what you can’t. It would be nice if Slime could be extended to other platforms, but their RB implementations are currently not compatible enough (a perfect target for Grease!).

Grease will continue to be part of the Seaside project and to be driven, for now, primarily by Seaside’s requirements. But we hope other projects will find it increasingly useful over time. Since each platform has already ported it, you may already be able to leverage it to provide increased consistency and portability for your applications. For the moment, consider Grease a prerelease and subject to major change; it will track Seaside releases for now, though I’m thinking of assigning independent version numbers to Grease releases to make things clearer.

The Grease packages can be found in the Seaside 3.0 repository or through your vendor's standard code distribution mechanism.