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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,76ec5d55630beb71 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-04 00:39:56 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!fu-berlin.de!uni-berlin.de!213.200.246.247!not-for-mail From: Vinzent Hoefler Newsgroups: comp.lang.ada Subject: Re: Ada 200X Date: Wed, 04 Jun 2003 09:38:35 +0200 Organization: JeLlyFish software Message-ID: References: <3EDAD07A.3010200@attbi.com> <3EDB5DBE.4070807@attbi.com> <3EDBBC18.6080103@attbi.com> <3EDCB68D.9070802@attbi.com> NNTP-Posting-Host: 213.200.246.247 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: fu-berlin.de 1054712394 9345038 213.200.246.247 (16 [175126]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:38570 Date: 2003-06-04T09:38:35+02:00 List-Id: Robert I. Eachus wrote: >Vinzent Hoefler wrote: > [snip] >> This rather looks like a tree. And I doubt, any medium sized OO-System >> would be much different from that just because it's Ada. > >First, lets get a view that doesn't hide the structure: > >TObject > TView > TScrollBar > TStaticText > TLabel > TParamText > TInputLine > THistory > TCluster > TRadioButtons > TCheckBoxes > TMultiCheckBoxes > TListViewer > TListBox > THistoryViewer > TGroup > TWindow > THistoryWindow > TDialog > >Let's actually put our Ada hats on and look at that hierarchy. The=20 >TObject vs. TView looks to be methodological not logical. It is kind of both, TObject has some more children (I mentioned it's just a part of the whole hierarchy, but to post the whole hierarchy would probably take a *lot* of lines), TView is simply the base object for anything that has a Draw method to show itself on the screen, the other children are objects that are not visible (like TPoint, TRect[angle] or TValidator). IIRC, the reason all these are derived from an empty base object is that the VMT has to be on the same place for storing and loading these objects in/from streams for them. So the decision for TObject/TView can be considered as a pure implementation issue. >Notice that=20 >there is a descendent TListViewer, which is the only view related direct= =20 >child.) It's just the name. Any children of TView can be displayed. :) >TView has seven children. In fact it has more. > If you redid this in Ada, I don't=20 >know if TCluster and TGroup would remain as 'real' children but I am=20 >sure that TWindow would get elevated. Despite the quite similar name, this has very good reasons, TGroup is for Objects that can be linked together, send their messaged through and have appropriate Select/SelectNext methods whilst TCluster are just objects that have a Mark method for selecting items (the classical Radiobuttons and Checkboxes). > A typical Ada Model-View=20 >hierarchy would have Object and View as parents and most other types=20 >descended from one or the other. Well, I don't think so. If I would redo Borland's stuff from scratch it would probably look different but not *that* different. >Of course, if I were to reimplement this hierarchy in Ada, I'd try as=20 >hard as possible to keep the original structure. Yes, and then you would encounter that when you do your own DialogBox you have to call its parent's Init-Constructor (because this one will initialize the color scheme, border, title bar and such things that you don't want to do each time by yourself). And when after then you decide that you implement a Dialog Box that always displays an Ok-Button and insert it into the hierarchy inbetween your Fancy_Dialog and the TDialog object you will encounter the problem that the Ok-Button doesn't display because you still call the TDialog's Init instead of the TDialog_OkBox's Init. This is where the "inherited" keyword comes handy, so the compiler automatically selects the TDialog_OkBox's Init and if this isn't implemented in a particular case (in this example it would be) it selects the TDialog's Init instead and so on... So you wouldn't have to change the code of your new Fancy_Dialog just because you decided to save the work to insert the Ok-Button in any of your own Dialog manually [Dialogs badly *need* an Ok-Button, don't they? ;-)] and instead introduce another Dialog-object in the hierarchy to do that automatically for you. >I might or might not=20 >manage to swallow the naming convention though. ;-) Well yes, because having Pxxx for the pointer types to their Txxx wouldn't be necessary, I guess. Vinzent. --=20 Parents strongly cautioned -- this posting is intended for mature audiences over 18. It may contain some material that many parents would not find suitable for children and may include intense violence, sexual situations, coarse language and suggestive dialogue.