Enumerations and Arrays Unnecessary!???

Enumerations and Arrays Unnecessary!???

[JR Crosmer]

In the past six months I have a course in object oriented design and
another one in object oreinted design (5-days each) .  In each course
the instructor insisted rather stronly that "There is no need for
enumeration types or array types."  Neither instructor had any
familiarity with Ada83 or Ada95.  They each suggested that an
enumeration litteral be thought of as an object: e.g., send a message to
the color Red to do something.  Thay also insisted that in any
situations in which an array is used, the implementation is not a good
fit to the underlying problem.

In my experience, I would be very hard pressed to give up either 
enumerations or arrays, especially with the capabilities allowed
and enhanced with Ada attributes and data typing rules.

In contrast, in C, C++ or Java, enumerations have almost no capability
since they are treated mostly as named integers w/respect to name space
and type compatibility.  In particular, these languages are especially
barren when trying to code a situation such as this one:

    type Color_Type is (Red, Green, Blue);
 
    type Color_Vector_Type is
            array (Color_Type) of ...some-element-type....;

Any thoughts from other Ada, C++ or Jave programmers?

JR Crosmer

Re: Enumerations and Arrays Unnecessary!???

[Robert Dewar]

JR Crosmer says

<<In the past six months I have a course in object oriented design and
another one in object oreinted design (5-days each) .  In each course
the instructor insisted rather stronly that "There is no need for
enumeration types or array types."  Neither instructor had any
familiarity with Ada83 or Ada95.  They each suggested that an
enumeration litteral be thought of as an object: e.g., send a message to
the color Red to do something.  Thay also insisted that in any
situations in which an array is used, the implementation is not a good
fit to the underlying problem.
 
In my experience, I would be very hard pressed to give up either 
enumerations or arrays, especially with the capabilities allowed
and enhanced with Ada attributes and data typing rules.>>


Whenever a new idea comes along in the software world, it seems to attract
a bunch of fanatics who get so enthusiastic about the approach that they
decide that using any other technique is completely unacceptable. Some
examples are

Never write a program without proving it correct

Use only referentially pure functional languages

Use only systematic top down refinement, no bottom up programming allowed

Use only language xxx (and yes I would include Ada, I have been amazed at
the past by some fanatics insisting on recoding perfectly good libraries
written in other languages).

...

And now, use only object oriented design.

A good rule is to take ALL advice from such fanatics with a huge grain of
salt. What experience shows is that software is complex, and we need all
the useful tools and techniques we can find, and we need to learn how to
choose the right ones for the right job, and how to make them work together.

Sometimes these fanatics give me an image of a salesman who comes along and
says "I have this wonderful new plumbing tool, it will do everything, and
you can have it free. The only catch is, you have to give me all your other
tools, and promise to use only this wonderful new tool from now on."

Object oriented design, and associated OOP features in languages are definitely
useful. But they are not the only way of doing things, and I often see programs
which have been made heavier, less efficient, less maintainable, less
readable, and more complex by ludicrous misuse of object oriented approaches.
Treating an enumeration literal like Red as an object is almost a
characature of such a mistake, and is definitely in the ludicrous category.

So, I hope you learned something useful to use in your courses, but whenever
you hear these folks telling you NOT to use something that you have found
useful, switch to reading comic books till they have finished the sermon :-)

As for arrays, there the issue is a little less clear. As a data structure,
it is true that arrays are often too low level, and it is useful and
appropriate to abstract from the structure. For example, if you look in 
the GNAT sources, the Node_Id values that are used to identify nodes in
the tree are in fact subscripts in an underlying array, but this is not
something that is visible or used at the abstraction level.

On the other hand, as a storage structure, arrays are fundamental. A language
that does not provide arrays at all is severely hampered. There are 
algorithms which absolutely require random access of the type provided by
array references to perform as expected. There have been languages with
no arrays, notably original LISP, but in real modern LISP systems you will
cerainly find arrays available as a storage structure, although it is not
the style to use these extensively at a high level of abstraction.

Of course if you are dealing with mathematical concepts involving vectors
and arrays, then arrays are the appropriate abstraction, and suggesting
otherwise is again ludicrous nonsense (I would not be surprised if the
instructor of your course never wrote a serious numerical code -- many
programmers have not).

Robert Dewar

P.S. Oddly enough, although these days I never write numerical code, once I
did, since my thesis 30 years ago was in Crystallography, and some of the
Fortran code I wrote them is still in wide use :-)

Fanaticism [was Re: Enumerations and Arrays Unnecessary!???]

[Jan Galkowski]

Robert Dewar wrote:
> 
> JR Crosmer says

[snip]

> 
> Whenever a new idea comes along in the software world, it seems to attract
> a bunch of fanatics who get so enthusiastic about the approach that they
> decide that using any other technique is completely unacceptable. Some
> examples are
> 
> Never write a program without proving it correct
> 
> Use only referentially pure functional languages
>

Ah, alas, at last, we fanatics we get into the picture!

[snip]

> And now, use only object oriented design.
> 
> A good rule is to take ALL advice from such fanatics with a huge grain of
> salt. What experience shows is that software is complex, and we need all
> the useful tools and techniques we can find, and we need to learn how to
> choose the right ones for the right job, and how to make them work together.

While this is most definitely true and the rule today, it is so because the
methods of proving programs correct or, rather, the methods of constructing 
correct programs from scratch are new, not well developed, and the means of
teaching them and applying them are very crude.  Therefore, I surmise that
someday the rather hobbyist approach to development and programming we see
today will be less the rule, and low-level design will become more a matter of
rote execution than inspired.  This means that there will be less reliance
upon the truly gifted and "heroes" than there is today.  

This opinion is totally unprovable, of course. I can only cite plausible
arugments and interesting historial aphorisms, such as the one by (Harlan)
Mills that touch-typing was a skill needed for the proper
use and appreciation of typewriters, the latter languishing for much of
the 19th century, even among the most influential in society, because this
crucial skill was not widely taught or appreciated.  It is, IMO, in the
interest of business to make expensive programming skills as widespread and
mundane as possible, even though this is very difficult today. 

> 
> Sometimes these fanatics give me an image of a salesman who comes along and
> says "I have this wonderful new plumbing tool, it will do everything, and
> you can have it free. The only catch is, you have to give me all your other
> tools, and promise to use only this wonderful new tool from now on."
> 

But tools for programming are rather more like each other than screwdrivers
and hammers.  (Hackers, of course, disagree with this vehemently.  For
them, programming is the bag of hacks bit.)

Moreover, it is the purpose of most schooling to teach the technologies of 
ten years hence, so it will be most useful to their customers, and so
they are not stuck in the muck of the practical and the everyday.  Yes,
that is the art, but it can be and usually is learned by apprenticeship,
not schooling.  So, it is a mistake, IMO, to not take these "pie in the
sky" technologies seriously enough, perhaps even a worse sin than taking
them too seriously.

[snip]

 
> Robert Dewar
> 

[snip]

-- 
 Jan Theodore Galkowski, 
 developer, statistician, 

                                       true
                                    confessions
                                        |
                                        V
  CONSTRUCTIVE ALGORITHMICS AND ICON FANATIC,
                                     ********

   Digicomp Research Corporation,
   Ithaca, NY 14850-5720
 jan@digicomp.com 
 (also jtgalkowski@worldnet.att.net)

Re: Enumerations and Arrays Unnecessary!???

[Robert A Duff]

In article <33A16AC0.1BA4@calvin.cca.rockwell.com>,
JR Crosmer  <jrc@calvin.cca.rockwell.com> wrote:
>In the past six months I have a course in object oriented design and
>another one in object oreinted design (5-days each) .

Heh?

>...In each course
>the instructor insisted rather stronly that "There is no need for
>enumeration types or array types."  Neither instructor had any
>familiarity with Ada83 or Ada95. ...

It's true that many uses of enumerations can be replaced with oop-ish
things.  If, in Ada 83, your enumeration type was the discriminant of a
variant record, then in Ada 95 a hierarchy of tagged types might be
appropriate instead.

But to say that enums are *never* a good idea seems silly.  For example,
consider type Character, which is an enumeration type.

As for arrays: It is true that arrays are often too low-level a feature.
You should use a Set or Sequence or Unbounded_String or whatever
abstraction instead.  But, you'll *implement* those abstractions in
terms of arrays, in many cases.

You say the professor didn't know Ada.  So perhaps the professor was
thinking of C, where enums are weaker, characters and integers are
confused, and the point about arrays is even *more* true since C arrays
are even lower level abstractions than Ada's arrays.

- Bob

Re: Enumerations and Arrays Unnecessary!???

[Robert Dewar]

Bob says

<<But to say that enums are *never* a good idea seems silly.  For example,
consider type Character, which is an enumeration type.>>


YOu mean that you don't see that Character is obviously a class, and
specific characters like 'C' '+' '+' are simply objects of that class
to which messages should be sent as required.

Gosh some people don't understand what programming is all about

:-) :-)

Robert

Re: Enumerations and Arrays Unnecessary!???

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.866335292@merv>...
> YOu mean that you don't see that Character is obviously a class, and
> specific characters like 'C' '+' '+' are simply objects of that class
> to which messages should be sent as required.

Conceptually, this is a perfectly reasonable idea. But imagine implementing
characters this way in Ada (where each character would be a tagged type).
Uh oh! Better still, imagine (as we are not allowed arrays either)
implementing strings as linked lists (or whatever) of these tagged types.
[Of course, this is roughly how languages such as (traditional) Prolog _do_
implement strings!]

Class CHARACTER would have obvious subclasses, such as LETTER and DIGIT,
with their own specialised constants and methods (such as FIRST, LAST,
NEXT, and VALUE). This approach is really not so silly, if it could be
implemented efficiently (in a language other than Ada).

I think this is an interesting question: could it be implemented
efficiently? In my ignorance, how does Smalltalk implement characters? And
other O. O. languages?

Nick.

Re: Enumerations and Arrays Unnecessary!???

[Robert A Duff]

In article <01bc7b84$5fa9e300$LocalHost@xhv46.dial.pipex.com>,
Nick Roberts <Nick.Roberts@dial.pipex.com> wrote:
>Class CHARACTER would have obvious subclasses, such as LETTER and DIGIT,
>with their own specialised constants and methods (such as FIRST, LAST,
>NEXT, and VALUE). This approach is really not so silly, if it could be
>implemented efficiently (in a language other than Ada).

I would insist on more than just efficiency: I also want the simple,
concise notation, as in Ada where you just write down the list of
literals, and the compiler handles the rest (e.g. making sure they are
each assigned a unique code).  I wouldn't want to laboriously define a
new class for each of Red, Green, Yellow, etc, if the syntax for class
definitions is longer than 2 tokens.

Note that in most OO languages, the subclasses of a class aren't ordered
in any particular way.  But you often want enumeration literals to be
ordered, so you can do "<" on them, and loop through them, and so forth.
You also want to be able to have arrays indexed by enumeration types,
which doesn't work in the subclass idea, unless you extend the notion of
classes quite a bit.

>I think this is an interesting question: could it be implemented
>efficiently?

It is possible to design a language such that this is efficient.

>... In my ignorance, how does Smalltalk implement characters? And
>other O. O. languages?

Smalltalk has a Character class built in, which internally holds an
integer number in the range 0..255.  There is special syntax for
character literals ($A in Smalltalk is like 'A' in Ada).  You couldn't
define your own character type in the same was as in Ada.  You don't get
subranges and case statements and so forth.  You can't simply declare an
array of Character and expect it to be efficient -- there's a special
built-in String class.  Character has no subclasses (that is, the letter
A is not represented by its own class, but simply by an integer
encoding).  There are isLetter, isDigit, etc methods, rather than
Letter, Digit, etc subclasses.

You could define your own Color class, with values red, green, etc, in a
similar manner.  But there's nothing particularly object-oriented about
it -- you're just assigning unique integer codes by hand.  The
"object-oriented" way would be to define classes Red, Green, etc as
subclasses of Color.  That's doable, but it's rather verbose if there
are a lot of literals.  Class Boolean is done this way.

Another way to get something like enumeration literals in Smalltalk is
to use Symbols.

- Bob

Re: Enumerations and Arrays Unnecessary!???

[David Wheeler]

Just a few random comments...

JR Crosmer (jrc@calvin.cca.rockwell.com) wrote:
: In the past six months I have a course in object oriented design and
: another one in object oreinted design (5-days each) .  In each course
: the instructor insisted rather stronly that "There is no need for
: enumeration types or array types."  Neither instructor had any
: familiarity with Ada83 or Ada95.  They each suggested that an
: enumeration litteral be thought of as an object: e.g., send a message to
: the color Red to do something.  Thay also insisted that in any
: situations in which an array is used, the implementation is not a good
: fit to the underlying problem.

: In my experience, I would be very hard pressed to give up either 
: enumerations or arrays, especially with the capabilities allowed
: and enhanced with Ada attributes and data typing rules.

Both arrays and enumerations are useful abstractions.
There's nothing wrong with thinking of an enumeration literal
as an object that receives messages, if that helps.

: In contrast, in C, C++ or Java, enumerations have almost no capability
: since they are treated mostly as named integers w/respect to name space
: and type compatibility.

You'd be hard-pressed to use enumerations in Java... Java doesn't
have the ability to define a new enumeration type.
This is one the weaknesses, not strengths, of
the Java language.  Java programs simulate enumerations by using
constants of various integer types, which unfortunately weakens
its ability to define interfaces well and eliminates a useful form of
error-checking.

It _is_ true that arrays are sometimes used when a better abstraction
should be used instead; some languages only support arrays and people
who only know such languages have trouble using richer capabilities.
Still, many mathematical routines would be hard to understand without arrays.

In summary: use the tool that's best for your problem.


--- David A. Wheeler
    dwheeler@ida.org