Enumerations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Enumerations

Steffen Märcker
Hi,

what is your preferred smalltalkish way to model enums with instance  
specific behavior and why? For example, I could define an abstract class,  
say MyEnum, and a singleton subclass for each item.

Ciao, Steffen
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Enumerations

Michael Lucas-Smith-2
Unless I'm modelling a C enum in Smalltalk, I just use symbols. If the symbols have to represent something other than themselves, as is the case in C where they represent an integer, I'll use a dictionary - if it has to be performant, I'll use a binding instead. If it has to be really performant, I'll use an instance variable initialised to the specific numbers. But usually, enumerations-wise, it's just symbolic.

Cheers,
Michael

On 27/05/2013, at 5:16 PM, Steffen Märcker <[hidden email]> wrote:

> Hi,
>
> what is your preferred smalltalkish way to model enums with instance specific behavior and why? For example, I could define an abstract class, say MyEnum, and a singleton subclass for each item.
>
> Ciao, Steffen
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Enumerations

Steven Kelly
In reply to this post by Steffen Märcker
[vwnc] Enumerations
If the instance-specific behaviour differs in just one or two places, and there are only a couple of enumeration values, I'll just use ifTrue:/ifFalse:
 
method1
self myEnumValue == #firstEnum ifTrue: [self doTheFirstKind] ifFalse: [self doTheSecondKind].
 
method2
self myEnumValue == #firstEnum ifTrue: [self againItsTheFirstKind] ifFalse: [self doTheSecondKind].
 
If there are a few more enum values I'll use a dictionary, and/or start forming method names from the enum value and using perform:
 
method1
self perform: self myEnumValue
 
and if that starts to feel ugly, or there are more places that depend on the enum value, I'll use an abstract class and a subclass for each enum value. It wouldn't necessarily be a singleton subclass: if the enum is only used as an instance variable of one existing class, that class can be made abstract, the instance variable removed, and a subclass made for each enum value.
 
Personally I find that adding a set of classes always feels rather heavyweight. I know they're only objects, but the development tools give them a strong visibility, with no good way to highlight "real" classes over "Enum1, Enum2, Enum3" mini-classes.
 
Steve


From: [hidden email] on behalf of Steffen Märcker
Sent: Mon 27/05/2013 10:16
To: vwnc
Subject: [vwnc] Enumerations

Hi,

what is your preferred smalltalkish way to model enums with instance 
specific behavior and why? For example, I could define an abstract class, 
say MyEnum, and a singleton subclass for each item.

Ciao, Steffen
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Enumerations

Runar Jordahl
In reply to this post by Steffen Märcker
I like your approach. Many feels there are too many classes, but I disagree. As your model evolves, this solution gives you less clutter.

I have written a post about this topic here:

Runar Jordahl

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Enumerations

Vincent Lesbros-2
If the enum can represent object with complex behavior, 
I'll use an abstract class and a subclass for each enum value too (like steven says).
(and class methods if the calcultations are "static"), no instance needed..

but I like the "perform" way too.
and values like #enum1 #enum2 ... may be transformed into more complexe messages by, for example concatenating #":" at the end to pass a parameter. In this case, the responsibility is up to the recever (and any receiver  of #enum1: may have it's proper interprétation of the meaning of the enum).


2013/5/27 Runar Jordahl <[hidden email]>
I like your approach. Many feels there are too many classes, but I disagree. As your model evolves, this solution gives you less clutter.

I have written a post about this topic here:

Runar Jordahl

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc