From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8276b2994037cd71 X-Google-Attributes: gid103376,public From: dmitry6243@my-deja.com Subject: Re: disjoint ranges ? Date: 2000/10/24 Message-ID: <8t3h15$l2b$1@nnrp1.deja.com>#1/1 X-Deja-AN: 685145941 References: <39E612C9.9BF98CD3@laas.fr> <39E79F17.24DB0828@pacbell.net> <39E7BB80.1AB10FE2@ix.netcom.com> <39F48116.35EE68C9@earthlink.net> X-Http-Proxy: 1.0 x59.deja.com:80 (Squid/1.1.22) for client 212.79.192.251 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Tue Oct 24 08:25:12 2000 GMT X-MyDeja-Info: XMYDJUIDdmitry6243 Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.75 [en] (WinNT; U) Date: 2000-10-24T00:00:00+00:00 List-Id: In article <39F48116.35EE68C9@earthlink.net>, Charles Hixson 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.