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 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,15edb893ef79e231 X-Google-Attributes: gidfac41,public X-Google-Thread: f4fd2,23202754c9ce78dd X-Google-Attributes: gidf4fd2,public X-Google-Thread: 103376,15edb893ef79e231 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,15edb893ef79e231 X-Google-Attributes: gid114809,public X-Google-ArrivalTime: 2002-01-21 08:50:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: Richard Riehle Newsgroups: comp.lang.lisp,comp.lang.ada,comp.lang.eiffel,comp.lang.smalltalk Subject: Re: True faiths ( was Re: The true faith ) Date: Mon, 21 Jan 2002 08:38:39 -0800 Organization: AdaWorks Software Engineering Message-ID: <3C4C440F.3754144F@adaworks.com> References: <%njZ7.279$iR.150960@news3.calgary.shaw.ca> <3c36fbc5_10@news.newsgroups.com> <4idg3u40ermnp682n6igc5gudp7hajkea9@4ax.com> <76be8851.0201101909.9db0718@posting.google.com> <9jtu3u8cq92b05j47uat3412tok6hqu1ki@4ax.com> <3C3F8689.377A9F0F@brising.com> <3219936759616091@naggum.net> <3C483CE7.D61D1BF@removeme.gst.com> <3C4863C5.6040406@mail.com> <3C48AE35.BA38ED04@adaworks.com> <3C4A58B8.10304@mail.com> <3C4B720F.F77B2552@adaworks.com> <3C4BE556.7040707@mail.com> Reply-To: richard@adaworks.com NNTP-Posting-Host: 9e.fc.c5.30 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 21 Jan 2002 16:49:06 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.lisp:24862 comp.lang.ada:19145 comp.lang.eiffel:5485 comp.lang.smalltalk:18352 Date: 2002-01-21T16:49:06+00:00 List-Id: Hyman Rosen wrote: > But the user of a type generally isn't concerned with its innards. > Why would you take a simple concept like copying or assignment and > burden it with implementation details? If you were writing a sort > method for a conatiner, wouldn't you just call it "sort" rather than > "merge_sort' or "bubble_sort"? In fact, I do care about this. The performance characteristics of each kind of sort are important. Under some circumstances I want to use a Merge Sort utility and other times I want a Quicksort. This is one place where I can benefit from a knowledge of the Big O notation. > Well, the normal semantics of a copy are that the source and destination > are not tied to each other after the copy is made. Of course, internally > that might not be true, because you could be maintaining reference > counts, and doing copy-on-write. You would place all that information > into the routine name? I will want to have information in the contract that gives the client of my specification an opportunity to choose which method to invoke, and what to expect from it. It might be quite useful for a client to know that a method is managed or not managed, but this does not have to be part of the name. In my example, I included preconditions and postconditions in the form of meaningful exception names. These also provide some information for the client. In the legal world, there is something called "due notice." Any contract, including a type/class specfication, needs to be explicit. > And limited types are irrelevant here. C++ and Ada can both prevent > assignment from compiling. The problem was writing assignment correctly > when you do want to provide it. Actually, when considering the need for clarity, I think there is a difference. The technique for preventing assignment in C++ is not, in my mind, as clear as the declaration of a limited type. The fact that some construct can be expressed in a particular language does not mean it is best expressed in that language. We will simply have to agree to disagree on the point regarding limited types. Richard Riehle