Scoping Changes with Method Namespaces Alexandre Bergel ADAM Project, INRIA Futurs Lille, France [email protected] Abstract. Size and complexity of software has reached a point where modular constructs provided by traditional object-oriented programming languages are not expressive enough. A typical situation is how to modify a legacy code without breaking its existing clients. We propose method namespaces as a visibility mechanism for behavioral refine- ments of classes (method addition and redefinition). New methods may be added and existing methods may be redefined in a method namespace. This results in a new version of a class accessible only within the defining method namespace. This mechanism, complementary to inheritance in object-orientation and tradi- tional packages, allows unanticipated changes while minimizing the impact on former code. Method Namespaces have been implemented in the Squeak Smalltalk system and has been successfully used to provide a translated version of a library without ad- versely impacting its original clients. We also provide benchmarks that demon- strate its application in a practical setting. 1 Introduction Managing evolution and changes is a critical part of the life cycle of all software sys- tems [BMZ+05, NDGL06]. In software, changes are modeled as a set of incremental code refinements such as class redefinition, method addition, and method redefinition. Class-based object-oriented programming languages (OOP) models code refinements with subclasses that contain behavioral differences. It appears that subclassing is well adapted when evolution is anticipated. For example, most design patterns and frame- works rely on class inheritance to express future anticipated adaptation and evolution. However, subclassing does not as easily help in expressing unanticipated software evo- lution [FF98a, BDN05b]. The work presented in this paper is a revival of selector namespace implemented in Smallscript1 by Dave Simmons. In recent years, researchers have produced numerous constructs and languages ex- tensions to better modularize software changes. Class extensions a` la CLOS, Smalltalk enable and ObjectiveC method addition and redefinitions by a package different from the package that defined the method’s class. This mechanism has been recently adopted by AspectJ. However, the visibility of those extensions is global which lead to conflict- ing situations between concurrently developed extensions. This visibility problem is the focus of this paper. 1 www.smallscript.net 2 A. Bergel This paper presents Method Namespaces, a modular construct for OOP languages that consists a single parent namespace and a set of method definitions. When a method is defined, an associated annotation identifies its namespace. Method definitions in a namespace are accessible only within the defining namespace and its children. Since a method namespace has one parent namespace, a set of namespaces is structured as a tree. Method namespaces enable several versions of the same method to coexist with minimal confusion as to which version will be invoked. The runtime semantics of method namespaces is driven by its pellucid property: the system behaves as if methods defined in an ancestor namespaces were directly defined in the child namespace. Thus, a method namespace represents the scope for a particular version of a group of methods. By encapsulating a set of method implementations, a namespace has the ability to define a software refinement that may crosscut several classes. Such a refinement is visible only within the method namespace in which it is defined and in its descendent. Thanks to the scoping mechanism, conflicts between namespaces are eliminated. The paper is structured as follows: Section2 illustrates the issues encountered by the community around the Squeak Smalltalk when translating its libraries. Section3 describes the method namespace model and its properties. It also shows how the issues related to the translation are solved. Section4 presents the implementation of Method Namespaces in the Squeak Smalltalk system. Section5 presents the related work. Fi- nally, Section6 concludes this paper and outlines our future work. 2 The Need for Scoping Changes Multilingual support. Managing unanticipated software evolution has been a software engineering problem that attracts a large interest [MFH01, FF98b, TB99, BMZ+05]. This section describes a situation that the Squeak2 [IKM+97] community has encoun- tered when adding a multilingual support. Before this translation effort, English was ubiquitous in all object descriptions and tool implementations. For example, the class Object defines a method printOn: aStream as follows: Object>>printOn: aStream ”Append to the argument, aStream, a sequence of characters that identifies the receiver.” j title j title := self class name. aStream nextPutAll: (title first isVowel ifTrue: [’an ’] ifFalse: [’a ’]); nextPutAll: title This method simply prepends an article before the name of the object’s class. Print- ing an object into a stream invokes this method. For example, the printing of an instance of a Car class returns a Car and an instance of Object returns an Object. 2 www.squeak.org Scoping Changes with Method Namespaces 3 Multilingual support is achieved by invoking the message translate on each used string. For example, a multilingual version of printOn: aStream contains ’an ’ translated and ’a ’ translated instead. This translate method is defined on the String class and per- forms a lookup into a global translation dictionary; ’a ’ and ’an ’ will translate into ’un ’ for a French translation. Need for coexisting versions. Parts of Squeak were refactored by adding such translate message send to strings. Whereas this mechanism may be sufficient for menus and win- dows title, it fails whenever a particular convention or sentence structure has to be taken into account. For example, the method Date>>fromString: aString is used to convert a textual date representation into an instance of the Date class. A typical illustration is Date fromString: ’August 12, 2007’. The parameter of fromString: aString may match different patterns such as ’8/12/2007’. The parameter aString has to follow the Ameri- can english way of writting dates (month followed by the day, then the year). In most European countries, a date starts with the day followed by the month and the year as in 12/8/2007. Implementing a multilingual mechanism cannot be achieved by translating strings only. A different parsing for dates has to be employed instead. A similar situa- tion occurs with reading and printing of time. Hours range from 0 and 23 or from 1 and 12. The two fromString: aString methods defined on Date and Time have to be rewrit- ten in order to have a proper French translation. However, the Squeak runtime makes a heavy use of those methods. Parts related to the system event logging and source code change versioning rely on the original version of the Date and Time classes. For exam- ple, the DPRecentlyModified class augments the system code browser by informing the programmer about the recently modified methods. Determining whether a method is re- cent is achieved by comparing method time stamps. Those time stamps are extracted as a string from the list of changes separately stored in a file. Next, instances of Date and Time are obtained using the fromString: aString conversion methods defined in those classes. As a consequence, replacing the American English version of fromString: aS- tring with the French version will not correctly handle legacy time stamps that are stored (using the American English format) since a method modified on January 12 has been stored under the ’1/12/2007’ in the list of changes. When read back by the DPRecent- lyModified class, this time stamp appears to be December 1st using the French format. The list of recently modified methods will therefore be incorrect. This example demonstrates the difficulty of updating parts of a system while pre- serving original system behavior. A complete multilingual version of Squeak must han- dle different time and date formats properly. However the Squeak core implicitly as- sumes that the format of already stored time stamps follows the American English con- version methods, which is not the case if modifications to Date and Time are universally visible. Limitation of class inheritance. Creating two new classes FrenchDate and FrenchTime that would subclass Date and Time, respectively, is not satisfactory since all references to those classes will have to be reviewed and possibly updated to reference the new subclasses. For example, among the 5002 classes present in the development version of 4 A. Bergel the Squeak system3, Date is referenced 80 times and Time 236 times. Subclassing these two classes will imply heavy rewritings to make the French subclasses used by some, but not all of the legacy code. This limitation of inheritance to express incremental re- finements has been extensively described in the literature [FF98a, BDN05b]. Problem analysis. The solution to address the issue described above will have to exhibit four properties: – Coexistance of multiple implementations. Adding a multilingual support as de- scribed above is a typical situation where at least two implementations for a same method must coexist: one needed by the Squeak runtime to deal with system noti- fication and logging and another to be used by the client program. – Scoping of implementations. Incorporating the French translation in the Squeak system is not practical because of the global impact this translation has. The French version of methods should be scoped in order to avoid any unanticipated impact on the base system. The application user that requires the French translation should run in a scope where the changes related to the translation are effective. Outside this scope, those changes should not be in effect: the Squeak versioning and changes logging mecha- nisms should stick to the American English way of storing dates and times to avoid confusion with the legacy data. – Class identity and class refinement. As we have seen, subclassing is not satisfactory because a newly created class cannot be used by legacy code.