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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.8.169 with SMTP id h41mr15575361ioi.66.1512477347104; Tue, 05 Dec 2017 04:35:47 -0800 (PST) X-Received: by 10.157.85.67 with SMTP id h3mr818175oti.10.1512477347018; Tue, 05 Dec 2017 04:35:47 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.kjsl.com!usenet.stanford.edu!193no1778505itr.0!news-out.google.com!s63ni4653itb.0!nntp.google.com!193no1778501itr.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 5 Dec 2017 04:35:46 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.71.208.22; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 173.71.208.22 References: <889a3aed-4e6b-49c8-8c1c-6f1478e8e077@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Full view of a private partial view cannot be a subtype From: Jere Injection-Date: Tue, 05 Dec 2017 12:35:47 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:49376 Date: 2017-12-05T04:35:46-08:00 List-Id: On Monday, December 4, 2017 at 4:48:34 PM UTC-5, Jeffrey R. Carter wrote: > 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. > You run into the same issues with composition (only in my view worse). With composition you still have to look up each component's file to see it's operations and worse yet you have no tools that can help you extrapolate what operations are available from a higher level component. With extension you can at least use auto completion lists to see what all the options are. With composition you are stuck doing X. then X.Y. then X.Y.Z. and so on. Then the component chaining when wanting to call an ancestor's operation can quickly blow up with composition (as opposed to extension where there is a single level). You can simplify this by creating forwarding functions in the higher level components, but that is analogous to adding overloads in the higher level components for extension. For either it is optional. > With a composition approach you would at a minimum have a list of every > operation on every type right there with the type declaration. This phrasing makes me think you are comparing private composition vs public extension. If so, it would be more fair to compare private composition vs private extension. Both of those require at a minimum have a list of every operation on every type right there with the type declaration. Perhaps this is really more an issue of private vs public inheritance? > > 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. > I respect yall's view on this, but in either case it is still a subjective matter. There are a variety of people out there who all view things very differently. On a side note, I hope I do not sound too combative. I really do appreciate your input and your views. I've read most of your papers and have enjoyed them. Even if I don't agree with a specific point, I still try to re-evaluate my own decision based on what you are suggesting.