What is the idiomatic way to define an enum type in Smalltalk? - smalltalk

Question

Like in Java, C# etc. How would I define something like enum Direction { input, output } in Smalltalk?

Answer 1

Trivial Approach
The most trivial approach is to have class-side methods returning symbols or other basic objects (such as integers).
So you can write your example as follows:
Direction class>>input
^ #input
Direction class>>output
^ #output
And the usage:
Direction input
The main downsides are:
any other "enum" that happens to return the same value will equals to this one, even though the enums are different (you could return e.g. ^ self name + '::input')
during debugging, you see the actual value of the object, which is especially ugly for number-based enums (Uh... what does this 7 mean?)
Object Approach
A better way is to create your own enum object and return instances of it.
Such object should:
override = and hash, so you can compare them by your value and use the enum as key in hashed collections (dictionaries)
store the actual unique value representation
have custom printOn: method to ease debugging
It could look something like this
Object subclass: #DirectionEnum
slots: { #value }
classVariables: { }
category: 'DirectionEnum'
"enum accessors"
DirectionEnum class>>input
^ self new value: #input
DirectionEnum class>>output
^ self new value: #output
"getter/setters"
DirectionEnum>>value
^ value
DirectionEnum>>value: aValue
value := aValue
"comparing"
DirectionEnum>>= anEnum
^ self class = anEnum class and: [ self value = anEnum value ]
DirectionEnum>>hash
^ self class hash bitXor: self value hash
"printing"
DirectionEnum>>printOn: aStream
super printOn: aStream.
aStream << '(' << self value asString << ')'
the usage is still the same
Direction input.
DirectionEnum output asString. "'a DirectionEnum(output)'"
and the problems mentioned in the trivial approach are resolved.
Obviously this is much more work, but the result is better. If you have many enums, then it could make sense to move the basic behavior to a new superclass Enum, and then DirectionEnum would just need to contain the class-side methods.

Answer 2

The closest Smalltalk feature to an enum type is the SharedPool (a.k.a. PoolDictionary). Therefore, if you are porting some enum from, say, Java to Smalltalk, you might want to use a SharedPool. Here is how to do so:
For every enum in your type you will define an association in the pool with key the type name and value the type value.
In some dialects PoolDictionaries are dictionaries, in Pharo they are subclasses of SharedPool. In Pharo, therefore, you declare all the type names as class variables. Then you associate values to keys in an initialization method (class side).
For example, you could define a subclass of SharedPool named ColorConstants with the class variables 'Red', 'Green', 'Blue', 'Black', 'White', etc., like this:
SharedPool
subclass: #ColorConstants
instanceVariableNames: ''
classVariableNames: 'Red Green Blue Black White'
poolDictionaries: ''
package: 'MyPackage'
To associate names with values, add a class side initialization method on the lines of:
ColorConstants class >> initialize
Red := Color r: 1 g: 0 b: 0.
Green := Color r: 0 g: 1 b: 0.
Blue := Color r: 0 g: 0 b: 1.
Black := Color r: 0 g: 0 b: 0.
White := Color r: 1 g: 1 b: 1.
"and so on..."
Once you evaluate ColorConstants initialize you will be able to use the pool in your class
Object
subclass: #MyClass
instanceVariableNames: 'blah'
classVariableNames: ''
poolDictionaries: 'ColorConstants'
package: 'MyPackage'
In MyClass (and its subclasses) you can refer to the colors by name:
MyClass >> displayError: aString
self display: aString foreground: Red background: White
MyClass >> displayOk: aString
self display: aString foreground: Green background: Black

Answer 3

For simple cases, just use symbols as Peter suggested - you could also just store the possible values in an IdentityDictionary.
If you mean the more powerful kind of enums that are available in Java (where they can be more than just a type of named constant; they can have behaviour, complex attributes, etc.), then I'd take it a step further than Peter and just create a subclass for each enum type. Even if you're talking a large number of enums (your use case seems to need only two), don't be afraid of having many subclasses that only have one or two methods in them that are just used to differentiate them from each other, with most of the work done in the common superclass.

Answer 4

Since Smalltalk is dynamically typed, you cannot restrict the value of a variable to a subset of objects anyway, so there is no difference between enum members and global constants, except for the namespacing through the enum name.
Edit: For options how to define your enum constants, see Peter's answer. Just let me mention that you can also use symbols directly if it is sufficient for your needs. direction := #input. direction := #output