GENERICS AND REVERSE GENERICS FOR PHARO Alexandre Bergel1∗ and Lorenzo Bettini2† 1Pleiad Lab, Computer Science Department (DCC), University of Chile, Santiago, Chile 2Dipartimento di Informatica, Universita` di Torino, Italy [email protected], [email protected] Keywords: Generic Programming, Pharo, Dynamically Typed Languages. Abstract: Generic programming is a mechanism for re-using code by abstracting specific types used in classes and programs. In this paper, we present a mechanism for adding generic programming in dynamically typed languages, showing how programmers can benefit from generic programming. Furthermore, we enhance the expressiveness of generic programming with reverse generics, a mechanism for automatically deriving new generic code starting from existing non-generic one. We implemented generics and reverse generics in Pharo Smalltalk, and we successfully used them to solve a problem of reusing unit test cases. This helped us to identify a number of bugs and anomalies in the stream class hierarchy. 1 Introduction mechanisms are effective when future extensions are foreseen. They provide little help in a scenario of The notion of generic programming has been orig- unanticipated code evolution in which the program- inally introduced in statically typed programming lan- ming language does provide dedicated evolutionary guages to ease manipulation and reuse of collection construct. This paper is about fixing this issue for dy- classes and algorithms. On the other hand, because of namically typed languages using generics. their flexible type systems, dynamically typed object- As popularized by mainstream statically typed oriented languages have been left out of the scope of programming languages, generic programming pro- generic programming. The need for generic program- vides a mechanism for defining template classes ming in a dynamically typed setting has been less where some types are variables/parameters and then prominent since no restriction applies over the kind for providing arguments for those type variables, thus of elements a collection may contain. instantiating template classes into concrete and com- Furthermore, in a dynamically typed language like plete classes. In the following, we then use the Smalltalk, where types are absent in declarations of term template class to refer to a class where some linguistic entities (like methods, fields, local vari- types are parametrized; accordingly, we refer to a ables), it might look odd to talk about generic pro- concrete/complete class when all the arguments for gramming. However, there is still a crucial context parametrized types are provided. where types (i.e., class names) appear statically: class Reverse generics (Bergel and Bettini, 2011) is the references. When creating an object, the class name is dual mechanism that enables the definition of a tem- hardcoded in the program, and this makes the object plate class from a complete class. We call this mecha- instantiation process hard to abstract from. nism generalization. It allows obtaining a brand new There are well-known patterns to deal with this generic class from an existing class by “removing” problem, such as Factory Method (Gamma et al., hardwired class references, and by replacing them 1995), Dependency Injection (Fowler, 2004), Virtual with parametrized types. For instance, classes (Bracha et al., 2010) and ad-hoc linguistic G<T> = C>C’< constructs (Cohen and Gil, 2007). However, these generates the new generic class G<T> starting from the class C by replacing each reference of a class C’ ∗This author has been partially supported by Program U- INICIA 11/06 VID 2011, grant U-INICIA 11/06, University contained in C with the type parameter T in G. It is the of Chile, and FONDECYT 1120094. dual operation of the instantiation operation offered †This author was partially supported by MIUR (Project by generics. The generic G may be instantiated into PRIN 2008 DISCO). G<U> for a provided class U. Note that, the reverse generics mechanism satisfies the property related work and Section8 concludes the paper and C = (C>T<) <T>. gives some perspectives on future work. Finally, an important point is that the original class C remains unmodified. Indeed, reverse generics are useful under the basic assumptions that (i) the code to 2 Generics in Pharo be reused has to be left intact (it cannot be the subject of refactoring) and (ii) the host programming does not This section presents a mechanism for generic implicitly support for looking up classes dynamically programming for the Pharo/Smalltalk programming (as this is the case in most dynamically languages, ex- language3. The presentation of the mechanism is cept NewSpeak the supports virtual classes (Bracha driven by a test-reuse scenario. We will first define a et al., 2010)). In particular, we aim at providing, test called GCollectionTest. This test will be free from a through our implementation of reverse generics, a particular class of the collection framework. GCollec- generative approach, where new generic code is (au- tionTest will be instantiated twice, for two different fix- tomatically) generated starting from existing one, and tures based on OrderedCollection and SortedCollection4. the latter will not be modified at all; for this reason, Consider the following code snippet containing a reverse generics are not, and they do not aim at, a test that verifies elements addition. refactoring technique (we also refer to Section7). ”Creation of the class T” This paper extends the Pharo Smalltalk program- GenericParameter subclass: #T ming language with generics and reverse generics. We adapted the reverse generics to cope with the ”Creation of the class GCollectionTest with a variable” lack of static type information (in (Bergel and Bettini, TestCase subclass: #GCollectionTest 2011) reverse generics were studied in the context of instanceVariableNames: ’collection’ statically typed languages such as Java and C++). Re- quirements on type parameters can be defined as a ”Definition of the setUp method” ”It instantiates T and add 3 numbers in it” safety net for a sound instantiation; we provide mech- GCollectionTest>> setUp anisms for structural and nominal requirements both collection := T new. for generics and reverse generics in Pharo. collection add: 4; add: 5; add: 10. The generic mechanisms we implemented do not depend on any Pharo facilities suggesting that gener- ”Definition of the test method testAddition” ”It adds an element in the collection defined in setUp” ics and reverse generics are likely to be transpos- GCollectionTest>> testAddition able to other dynamically typed languages. Although j initialSize j it has been realized in a dialect of Smalltalk, noth- initialSize := collection size. ing prevents them from being applied to Ruby and collection add: 20. Python. Even though similar mechanisms have been self assert: (collection includes: 20). proposed in Groovy (Axelsen and Krogdahl, 2009), self assert: (collection size = (initialSize + 1)). to the best of our knowledge, this is the first attempt GCollectionTest is a pretty standard unit test in the to add a generic-like construct to Smalltalk. (The spirit of the xUnit framework (most of the 115 classes Groovy case is discussed in the related work section). that test the Pharo collection library follow a very We employed reverse generics to face a classical similar structure). No reference to a collection class code reuse problem. Unit tests in Pharo are inher- is made by GCollectionTest. The method setUp refers ited from Squeak, a Smalltalk dialect that served as to the empty class T. GCollectionTest may be instanti- a base for Pharo. Those tests have been written in a ated into OrderedCollectionTest and SortedCollectionTest rather disorganized and ad-hoc fashion. This situation as follows: serves as the running example of this paper and was ”Instantiate GCollectionTest and replace encountered when evolving the Pharo runtime. This occurrences of T by OrderedCollection” helped us identify a number of bugs and anomalies in (GCollectionTest @ T-> OrderedCollection) the stream class hierarchy. as: #OrderedCollectionTest The contributions and innovations of this paper are summarized as follows: (i) definition of a mecha- ”Replace T by SortedCollection” (GCollectionTest @ T -> SortedCollection) nism for generics in Pharo (Section2); (ii) description as: #SortedCollectionTest of the reverse generics model in Pharo (Section4); (iii) description of the implementation of both mech- 3http://www.pharo-project.org anisms (Section5); (iv) applicability to a non triv- 4A fixture refers to the fixed state used as a baseline for ial case study (Section6). Section7 summarizes the tests. We consider the setUp method only in our situation. The generic class GCollectionTest has been instan- Structural requirements. In addition to nominal re- tiated twice, each time assigning a different class to quirements, a generic parameter may be also struc- the parameter T. We adopted the convention of defin- turally constrained. A constraint is satisfied based on ing generic parameter as subclasses of GenericParam- the presence of some particular methods. In the ex- eter. This convention has a number of advantages, as ample above, a method check may return discussed in Section5. Since GCollectionTest contains myself includesSelectors: f#add: . #includes: . #sizeg references to T, it is a generic class. There is therefore no syntactic distinction between a class and a generic In that case, only a class that implements the method class.