ANSI Smalltalk Compliance Testing

One of the primary goals of the Bistro project is to support the ANSI standard Smalltalk behaviors. The ANSI Smalltalk standard defines the type signatures of the methods that must be included in a compliant Smalltalk implemention. Because Bistro supports (optional) type annotations, it should be possible to simplify the compliance tests by defining the ANSI Smalltalk behaviors as Bistro types and metatypes. The package org.ansi.smalltalk was developed for this purpose.

The following conventions were used in defining the ANSI Smalltalk types in org.ansi.smalltalk.

• All the type names use the prevailing Smalltalk class naming conventions, i.e., mixed case with leading upper case.
• ANY has been renamed Any.
• RECEIVER has been replaced by the appropriate type name based on the type in which it appears.
• Where a method specification indicates "none" for a Return Value, the declared method returns void.
• Where a method specification indicates UNSPECIFIED for a Return Value, the declared method returns Object.
• Where a method specification indicates the return of alternative types (e.g., Nil or ClassDescription), the declared method returns the nearest common supertype (usually Object).
• All class and factory protocols are declared as metatypes in the appropriate subtype.
• Where appropriate, protocols are duplicated in a type and a metatype, e.g., ClassDescription is a type whose protocols are duplicated in the Object metatype.

The ANSI Smalltalk standard specifies refinement method protocols in subtypes that override similarly named methods in supertypes. However, due to the limitations of the Java™ type system, these method refinements are not declared in the org.ansi.smalltalk types, as they would often create conflicts in the generated Java™ interfaces.

The approach to using org.ansi.smalltalk for compliance testing has not been finalized. Two possibilities warrant investigation.

1. The standard ANSI types might be directly integrated into the Bistro class library.
2. A separate library of wrapper classes might implement the ANSI types.
3. The ANSI types might be implemented using Java™ dynamic proxy classes.

Experimentation with the first approach led to a proliferation of wrapper methods distributed throughout the Bistro class library. This approach was abandoned after the initial experiments because of the impact it entails on the library. However, if experiments with the two remaining approaches do not offer better prospects, the first approach will likely be revisited.

The second and third approaches will require a further parameterization of the Bistro runtime to support the configuration of the literal factories. Fortunately, the basic runtime already provides support for opaque literal factories. However, to support replacement of the basic literal factories with arbitrary ones will likely require further redesign and rework of the way literals are instantiated.

The final approach may be the most interesting and promising. However, it creates a dependency on JDK 1.3. This would further limit the Java™ platforms on which Bistro could be deployed. So, further investigation of this possibility will likely be deferred until uptake of JDK 1.3 becomes more pervasive throughout the industry.

Java™ is a trademark of Sun Microsystems, Inc.

Permission is granted to copy this document provided this copyright statement is retained in all copies.
Copyright 1999-2001 Nikolas S. Boyd.