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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Full view of a private partial view cannot be a subtype Date: Tue, 5 Dec 2017 21:39:14 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <889a3aed-4e6b-49c8-8c1c-6f1478e8e077@googlegroups.com> NNTP-Posting-Host: sWq1fEaAu/L5fGxxOY76vQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:49386 Date: 2017-12-05T21:39:14+01:00 List-Id: On 2017-12-05 19:16, Jeffrey R. Carter wrote: > On 12/05/2017 09:20 AM, Dmitry A. Kazakov wrote: >> >> If Button, Toggle_Button, Radio_Button etc were unrelated then in each >> event handler within a monstrous case over all possible widgets >> emitting the event, good luck finding their operations, cutting and >> pasting same code, you cannot reuse because types are unrelated. Yes, >> generics they will serve the final stroke to this insanity. > > If that were really the way you'd design such a thing if deprived of > type extension then I would to think you were incompetent to design S/W. > I wouldn't do it that way. It was your idea not mine. Either buttons are related types or not. There are three relationships between widgets: 1. Parent-child 2. Commonalities in widget appearance and functionality, e.g. buttons, menus etc 3. Publisher-subscriber to events, messages, signals The classic GUI design uses referential aggregation for #1, [multiple] inheritance for #2, weak references for #3. It is simply impossible to use aggregation for everything just because aggregation is hierarchic. It can be only one thing you could put there. >> You are welcome to propose one. After all it is only the interface you >> have to design. All the implementation can be based on an existing >> framework with inheritance and overriding... > > The problem with trying to build such a layer on top of an existing > framework is that they all use the C-inspired idea of giving up your > thread of control to the framework and it making calls to code you > provide. That's not how it should be done in a decent language. Firstly, it has no influence on the interface design. Secondly, you can always use a task monitor and route all calls through it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de