Re: disjoint ranges ?

[dmitry6243@my-deja.com]

In article <39F48116.35EE68C9@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:
> Lao Xiao Hai wrote:
>
> > ...
> > There are some in the world of object technology who believe that
enumerated
> > types are a bad idea because they are an artifact of an
old-fashioned style of
> > programming.   This same criticism could be leveled at the whole
issue of
> > range constraints.   While the notion of a range constraints was a
good one
> > when first introduced,  it could be argued that the problem
addressed by
> > a range constraint better can  be solved with assertions.  An
assertion would
> > enable easy modeling of non-contiguous ranges.   Of course, this
also makes
> > the compiler a bit more complicated and introduces other problems.
The
> > question is whether the new problems are worse than the old one
being
> > solved.
> > ...
>
> Many criticisms of features are based upon the way that C++ implements
the
> feature.  This is not exactly fair, but is perhaps inevitable as C++
is the most
> commonly known language.  Since Java is the second, and there is a
large overlap
> between the user base, perhaps if C++ does a poor job of implementing
a feature,
> and Java leaves it out, we can expect the feature itself to be
criticized.
>
> The assumption that there is some basic "right" way to do things is
probably
> wrong.  It seems to me that there are a range of correct ways, some
more suited to
> some problems, and others to others.

if 2 + 2 = 5 then
   5 := 4;
end if;    -- (:-))

(It isn't my invention. I forgot autor's name)

>  It also seems that there are a
range of ways
> to think, and that some are more suited to some programming
constructs, and others
> to others.  It's not really clear that one would gain anything by
shoehorning a
> construct where it didn't fit naturally.

Correct, but also requires an explanation why this or that construct
does not fit. Maybe it does not fit because some of already adopted
constructs fit even less than it.

>  Ada is designed, complex,
intricate,
> reliable, "small", and, especially, Formal.

... and regular.

However, there are lot of irregularities in Ada 95. One example is
missing procedural types (in presense of access procedural types).

>  This is seen in the Ada
implementation
> of Objects as Tagged records.  It makes perfect sense, after you think
about it
> long enough.  A tagged type makes explicit things which most
implementations of
> Objects leave implicit.

... for a very good reason: to hide implementation details.

IMO, Ada's way is very disputable (object=record, single inheritance, no
way to define supertypes, etc), except for one really EXCELLENT thing:
distinction between class-wide and "normal" values/pointers. This, I
believe, would allow (in some distant future (:-)) to have multiple
dispatch in Ada.

>  If you feel that these things should be
implicit, then you
> are more likely to feel that the members of an enumerated type should
be hidden
> behind the impermeable walls of a class.

It is of course a question whether enumerated types should be built-in.
I think they should.

Another question is whether they should be allowed to have methods
(impossible in Ada, because enumerated types are not tagged). There is
no big need in that, but I see no "physical" reason why they should not.

> But there are lots of problems with
> that.  The lack of enumerated types is one of Java's big weaknesses,
even if I
> don't like the way that C handles them.

Simply enums are so bad, that it was not a big loss. Lack of reasonable
enumerated types "supported" by comical visiblity rules is one of my
biggest problem when I'm switching from Ada to C++.

--
Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.