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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: A bad counterintuitive behaviour of Ada about OO Date: Fri, 8 Aug 2014 22:23:16 +0200 Organization: cbb software GmbH Message-ID: <9d40adts9g61$.1l95gb4s6ka9g$.dlg@40tude.net> References: <932kntuq5rrr.8sumwibqrufn.dlg@40tude.net> <1ohy7vnbntskq$.h139ov04mlxu$.dlg@40tude.net> <17wt4z4suijym$.fibkp6sw5itz$.dlg@40tude.net> <1k6qcfme6203h.1jon846ebrywu$.dlg@40tude.net> <1agzjp96wjs5e$.x9rvr6tl743l$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: pFv5JukiA5DRwd1gSNRC4g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:21579 Date: 2014-08-08T22:23:16+02:00 List-Id: On Fri, 08 Aug 2014 15:53:52 +0200, J-P. Rosen wrote: > Le 08/08/2014 15:11, Dmitry A. Kazakov a écrit : >>> Yes of course, but the /theory/ of it, and especially group theory etc. >>> that you mentioned is not a programmer's concern. >> >> How so? If integer is not ordered there is no "<" defined, if there is no >> "<" how are you going to have an ordered map with integer keys? > Well, of course the computer Integer has "<", but to use it I don't need > to know (nor do I give a damn) that it is a group, and that other types > are also groups. The question was about maps. Should maps be restricted strictly integer keys? >>> A generic can be applied to types that are not related in any way. >> >> They are related in exactly the way that this generic can be applied to >> them. Is the feature of being applicable in a generic relevant for >> programmers? I think it is. > The point is that of logical dependency. If I have a type T, and want to > use an operation defined on class C, I have to make my type a member of > C. And C has other members, that become somehow the brothers of T. LSP > means that they can be interchanged in some situations. So are formal generic types. They are somehow brothers and they can be interchanged in instantiations. You can instantiate a generic with one type or another. > Now, you can define the "class of all types that can instantiate G". > Possible, but useless. And having a useless class makes an advantage over having a useful class? I don't understand the logic. >>> This reminds me of a (bad) example of inheritance I once saw in a book: >>> the class "parrot" inherited from the class "human" because it needed >>> the method "can_speak". I'm somewhat uncomfortable with the notion that >>> a parrot is a special kind of human ;-). Well, it's a bad example >>> because inheritance should not be used just to grab any method you need. >> >> It is bad design, because the class of things that can speak is not the >> class of humans. Parrots and humans certainly participate in some classes, >> e.g. in Chordates, Tetrapoda etc. > The point is that often people write a method on a class, and then > inherit from it because they want to reuse a method. While you don't want to reuse any operations defined in a generic package. People put operations into generic packages out feeling of pure joy. No bad intentions to reuse them anyhow. Is that your point? >> There is >> tight relationship between operations =, /=, <, >, >=, <=, 'Prev, 'Next of >> an ordered set. This is what makes it such a thing. Inheriting to Ordered >> tells to the reader all this in just one source line. Moreover, it allows >> the compiler to check if the manifested type is indeed ordered and even >> prove some of this like x=y <=> not x/=y. > Certainly not. Inheriting from Ordered guarantees that all these > operations are available, but say nothing about the semantics. If you > want to add semantics, use type invariants and the like. Sure I can. And I can reuse Ordered interface in other places, probably put it into the standard library. And programmers can accustom to it as they are to built-in scalar types. >> Compare this with generics. They >> just name some operations and the programmer should guess about the purpose >> of what the actual type should be. Yes there is no dependency ... on the >> application domain. Just an ad-hoc mess. >> > It's not a mess. It's generality. The actual type should be anything > that matches the contract. The "contract" is a mess. It is not much better than C++ template "contract," anything that passes compilation is OK. Contracts must be verifiable, have predictable consequences, recognizable from the application domain. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de