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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c9629eba26884d78 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-07 07:58:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: XML DOM Binding for Ada 95 - matter of style Date: Thu, 07 Aug 2003 17:03:18 +0200 Message-ID: <0qm4jvgtbf3jibvf9vkdv9i4fvjrgn3soc@4ax.com> References: <3F2A5303.6080902@noplace.com> <3F2BA9C8.9030700@noplace.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1060268281 29574987 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:41231 Date: 2003-08-07T17:03:18+02:00 List-Id: On Thu, 07 Aug 2003 12:52:44 GMT, "Matthew Heaney" wrote: >"Dmitry A. Kazakov" wrote in message >news:egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com... >> On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus >> wrote: >> >> >Actually, you can pass operations of a tagged type as actuals. >> >> Yes, this is a great disadvantage of generics. You have to explicitly >> specify everything you need. > >This is a feature, not a flaw. The Ada generics were deliberately designed >this way, because you get better error checking. Yes. Better error checking is because of a better contract specification. Flaw is that with generics one cannot inherit the contract and extend/modify it. There are actually two ways to make something close to that: 1. To define a generic package with "interface" functions and pass its instance as formal parameter to another generic package. 2. To use child generic packages. Both are far not so flexible and easy to use as classical interface inheritance. >> Compare it with inheritance, you just >> specify a base type. This is because Ada's generics try to pretend to >> have some contract. > >I don't know what you mean by "pretend" to have a contract: Ada generics do >have a contract. In fact it's called the "generic contract model." A very limited one. There are many things, which cannot be [precisely] specified in the contract. For example, you cannot have user-defined type classes, you have to stick to the predefined ones, like "(<>)", "range <>", "mod <>", "private". There are problems with information hiding when generics are used. etc Anyway, if one wish to argue for generics against tagged types, one should rather consider C++ templates. All (mosty mythical) advantages over tagged types appear when one departs from the contract model. Stricter we make contracts lesser difference we will notice. As a prophecy, in the end, tagged types will completely supersede generics. >> C++ does not, it openly says that what you become >> is your own business. > >Well, yes and no. You don't just design ex nihilo, but with the expection >that the generic actual type will have a specific set of operations, even if >those operations are only loosely specified. > >> template void Sort ...; >> // Guess, what I have used here this week, "<=" or ">="? > >No. Sort will only use operator<. It will never use operator<= or >operator>=, because those can be derived from the canonical operator<. The contract states neither this nor otherwise. It is a clear flaw. One could argue that it is an advantage, because "every reasonable programmer would make so", but then I would argue that one need no type system at all, because "every reasonable programmer will never mix incompatible types". >You should always define relational operators in terms of the less-than >operatior: > >function "<" (L, R : T) return Boolean is ...; > >function ">" (L, R : T) return Boolean is >begin > return R < L; >end; > >function ">=" (L, R : T) return Boolean is >begin > return not (L < R); >end; > >function ">=" (L, R : T) return Boolean is >begin > return R <= L; >end; > >In the STL and in Charles, you even use the less-then operator for computing >"equivalence" of keys: > >function Is_Equivalent (L, R : T) return Boolean is >begin > return not (L < R) and not (R < L); >end; > >The equality operator "=" for elements is only used to compute the value of >container equality. How does this support templates? However this is a point for future Ada revisions. If the compiler derives "/=" from "=", why doesn't it for "<"? Similar thing is commutative operations like "+" and "*". One could wish to derive "+" (Left : Y; Right : X) from "+" (Left : X; Right : Y) instead of a geometric explosion of specifications in case of many types. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de