Enums?

Hi,

As an exercise, I'm planning to port a small set of C++ classes to
Smalltalk. They parse urls into its several components (protocol,
site, page, etc...). In C++ I have the different protocols (http,
https, ftp, etc...) as an enum.

How would this be done in Smalltalk? I have the gut feeling that enums
aren't the St way, but I'm not sure...

Fernando,

> How would this be done in Smalltalk? I have the gut feeling that enums
> aren't the St way, but I'm not sure...

You could use (one of the Smalltalk equivalents of) enums but you wouldn't
gain much - AFAIR enums are mainly about automatic type checking, which is
not really relevant in ST.

I would probably use Symbols in that situation, #http #ftp etc.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Hi, Fernando.

>As an exercise, I'm planning to port a small set of c++ classes to
>Smalltalk.

In my very personal experience, at first I was also tempted to port c++ code
into Smalltalk clases too, but after a couple of attempts, the results just
felt wrong. So I changed the approach, and tried rewriting it from scratch.
That was, in turn, an enligthen experience. Many abstractions emerged, and
many original clases were proved superfluous. The result with the "from
scratch" approach made me _much_ happier than just porting.

>How would this be done in Smalltalk? I have the gut feeling that enums
>aren't the St way, but I'm not sure...

As Ian said, they might be symbols. But I think there are also many reasons
why a programmer uses enums in c++ desings, and many of them are just the
absence of a better, simpler and more natural way of modeling things. It
depends on every particular case, but it happened to me that what in c++ was
an enum, turned out beeing a symbol, an instance of some other class, or a
class itself. What I mean is that perhaps there already may be objects in
your model (or will emerge on time) that eliminate the need of thinking in
terms of enums.

Best regards.
Martin Rubi.

Fernando,

> As an exercise, I'm planning to port a small set of C++ classes to
> Smalltalk. They parse urls into its several components (protocol,
> site, page, etc...). In C++ I have the different protocols (http,
> https, ftp, etc...) as an enum.
>
> How would this be done in Smalltalk? I have the gut feeling that enums
> aren't the St way, but I'm not sure...

I agree with Ian and Martin; you will likely find that the enums were a
crutch needed in C/C++, and that Smalltalk will offer you better approaches.

You might treat the protocols as symbols, and #perform: them as they
appear in the stream.  You could also use a dictionary with protocol
names as keys for blocks, message sends, selectors, etc. if you need
more flexibility.

Note that there is an existing Smalltalk web client for Dolphin (from
Steve Waring???).  It might provide some good examples for you.

Parsing URLs is something that will lend itself to test-driven
development, because the "answer" is well known in each case.  Give it a
try.  Also, be sure to throw in some stuff like

   http://www.somewhere.com/../../../winnt/command32.exe

which should probably raise an exception - unless you enjoy getting
hacked ;)

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

> How would this be done in Smalltalk? I have the gut feeling that enums
> aren't the St way, but I'm not sure...

It really depends on what you are doing.

If the enums are used to manage the current state of an object, then you are
better off introducing seperate state objects.

If the enums are capturing some sort of constant values. You could use pools

Or you could use a bunch of class methods. If you have an enum like so:

enum EContent { eWhitespace, eData };

create a new class

ContentEnum, and two class methods:

ContentEnum class>>whitespace
    ^0

ContentEnum class>>data
    ^1

still, imo, enums are usually better off repesented as individual objects.
The reason being is the enums are usually used in some sort of conditional
check, which would be better factored out into some sort of dispatched
interpretation type pattern.

On Mon, 17 Jan 2005 16:38:28 -0500, Bill Schwab
<[hidden email]> wrote:


>> As an exercise, I'm planning to port a small set of C++ classes to
>> Smalltalk. They parse urls into its several components (protocol,
>> site, page, etc...). In C++ I have the different protocols (http,
>> https, ftp, etc...) as an enum.
>>
>You might treat the protocols as symbols, and #perform: them as they
>appear in the stream.  You could also use a dictionary with protocol
>names as keys for blocks, message sends, selectors, etc. if you need
>more flexibility.

I checked the method comment for #perform:, but I don't get very well
its usage. Could you please elaborate on it's general usage and in
this specific context?

Thanks O:-)

On Tue, 18 Jan 2005 17:47:16 +0100, Fernando <[hidden email]> wrote:

> I checked the method comment for #perform:, but I don't get very well
> its usage. Could you please elaborate on it's general usage and in
> this specific context?

general: sends a message reflectively.

     anObject perform: #someMessageName.

is to do the following:

     anObject someMessageName

Ditto for the #perform: variants that supports arguments.

--
Regards
HweeBoon
MotionObj

Fernando,

> I checked the method comment for #perform:, but I don't get very well
> its usage. Could you please elaborate on it's general usage and in
> this specific context?

Try

    'hello' perform:'size' asSymbol


Then imagine

    aURLParser perform:( aReadStream upTo:$: ) asSymbol.

or something similar that reads the various parts of a URL and then uses
#perform: to invoke methods, taking the place of a switch statement in C*.

Note that with the additional power, you might want to think carefully
about security concerns.  In a pinch, you could always have a collection
of "safe" tokens, assert that the parsed value is in the collection (w/o
worrying which one it is), and the #peform: the string converted as a
symbol.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

> I checked the method comment for #perform:, but I don't get very well
> its usage. Could you please elaborate on it's general usage and in
> this specific context?

#perform:, like apply in Lisp, is a true function-call-by-name.
It says "Go do this thing whose name I will give you now."
This lets you invoke functionality directly
without having to design the other end of some integer isomorphism,
as you do with C-style enums.
Aggressive C programmers approach this with function pointers,
but you still have to map strings to pointers to do it.
#perform: is a lot more useful than it at first appears.
Some of the more difficult things you have to do in software
become very easy when you can invoke by name.

Steve

I have posted some thoughts about this at c.l.s.:
http://groups.google.com/groups?q=enumerated+runar+jordahl&hl=no&lr=&rls=GGLC,GGLC:1970-01,GGLC:en&selm=400c06f4%241%40news.broadpark.no&rnum=1

I think enums are best represented as one class per type.

Runar Jordahl
www.smallwalk.com