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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Full view of a private partial view cannot be a subtype Date: Mon, 4 Dec 2017 22:48:32 +0100 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <889a3aed-4e6b-49c8-8c1c-6f1478e8e077@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 4 Dec 2017 21:48:32 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="7a69b3c1b562598e493b87522700acec"; logging-data="26903"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/oMyOPI1DJ8X0I5ezWtpnoo3eGitjW8zk=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 In-Reply-To: Content-Language: en-US Cancel-Lock: sha1:ibzEbYrQMvpTl3tWVg24PqZWSkc= Xref: reader02.eternal-september.org comp.lang.ada:49370 Date: 2017-12-04T22:48:32+01:00 List-Id: On 12/04/2017 09:41 PM, Jere wrote: >> > I don't disagree in general per say, but that is a very subjective thing. I > don't find composition nearly as readable as you do. It has it's place and > can be more readable, but (maybe it's just how I read and visualize) I find > extension to be more readable in probably more cases than you typically do. > It's just a personal thing with how I read. I've used and written both. I've never seen a realistic problem that was as readable when implemented with type extension as with composition. Perhaps the best fit of any problem with type extension is a GUI framework, since everything "is-a" widget. I have used 2 such frameworks implemented using type extension, Claw and Gnoga, and both are very difficult to understand. The derivation trees are very deep and there are a huge number of inherited operations. It's effectively impossible to know all the operations for the most commonly used types, which tend to be down at the leaves of the derivation tree. Sometimes an operation behaves differently at different levels, with no indication that this should be expected. Even with a tool like GPS, which will bring up a list of completions when you type a dot after the name of something of a tagged type, is not very helpful when the list contains hundreds of possibilities. One tends to stick with the basics described in the examples and add a few additional things through experimentation, leaving a great deal of poorly understood and unused functionality in the framework. With a composition approach you would at a minimum have a list of every operation on every type right there with the type declaration. On real code at work I have seen 4 experienced people spend a half an hour analyzing a piece of code, tracing through the spaghetti of type extensions and dispatching to figure out what it was doing. Those 2 wasted person-hours could have been reduced by a factor of 4 or more had type extension been eschewed. I have been looking at this for over 2 decades and have yet to see a counterexample. If you think you know of one I'd like to see it. Maybe I'm weird and most people have no problem understanding these things, but I've seen plenty of other experienced people have similar difficulties, so I doubt it. JP Rosen wrote a paper, "What Orientation Should Ada's Objects Take?" (IIRC) that reached a similar conclusion. -- Jeff Carter "I would never want to belong to any club that would have someone like me for a member." Annie Hall 41