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 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63a41ccea0fc803a X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/07/26 Message-ID: #1/1 X-Deja-AN: 375044986 Sender: matt@mheaney.ni.net References: <6pdhfo$1br$1@platane.wanadoo.fr> <6petet$hff@drn.newsguy.com> NNTP-Posting-Date: Sun, 26 Jul 1998 08:09:10 PDT Newsgroups: comp.lang.ada Date: 1998-07-26T00:00:00+00:00 List-Id: nabbasi@earthlink.net writes: > offcourse a type is defined as set of values and set of operations. Yes. > I find it very hard in Ada to visualize an tagged object. but I can > easily visulaize a class object in Java or C++ becuase the class construct > makes it easy for me to do that. I don't understand your problem: type T is tagged private; is exactly equivalent to class T {... in C++. If the features of a type aren't obvious from reading the text of an Ada program, then something is probably wrong with the program, not the language itself. > when I used Ada, I use it as an object-based (as opposed to object-oriented) > langauge, which is what Ada was originally designed as, I do not use Ada for > its OO features. I like Ada as a procedural/object based, and for that it > is great. plus I think all the OO/inhertence stuff is way overrated > any way. Pete Wegner has done a lot of damage, I'm afraid. His classification of Ada 83 as object-based is incorrect. Ada 83 is properly classified as a type-based language (his term was "class-based," but I want to stick to Ada terminology). The addition of tagged types in Ada 95 is good, but it doesn't change implementation techniques that much from Ada 83, because you should already be using type-based abstractions where that makes sense. (I give some advice for knowing when to use a package vs when to use a type in the design patterns archives at the ACM website. Search for "singleton".). I agree, by the way, that inheritence as a re-use mechanism is way overrated. All it does is increase coupling, and make (deep) hierarchies too sensitive to changes in the classes near the root. Ada provides composition mechanisms that don't require inheritence. This means that if you're building deep inheritance hierarchies in Ada 95 ("deep" defined as more than 2 or 3 levels), then you're probably doing something wrong. Any normal system is going to require changes as it is built, so you'll have the compile-the-universe problem every time there's a change. > abstraction, data hiding, sepration of interfaces and implementaions, strong > typing, generics, good exception, good build-in tasking model, and all > that good stuff is good enough for me. If I want to do heavy/pure > OO stuff, I would not use Ada, just becuase I am not used to the OO > ways of Ada, it just too different from all the other OO languages > out there (different in how its OO features are reprsented offcourse, > the semactics are the same, but language representation (lexical > structure) is very important I think becuase it affect how one thinks > and visualize things), and in that the class structure is more natural than > tagged records + procedures that takes paramters or returns paramters > of types of that record. How you do it in Ada 95 is not much different from how you do it in Ada 83. If you think Ada 95 is "too different" from other oo languages, then you must think the same think about Ada 83, right? The Ada way has some advantages, because I can say this: if O1 = O2 then ...; instead of the klunky if O1.Is_Equal (O2) the ...;