Re: Ada 200X

[Vinzent Hoefler <ada.rocks@jlfencey.com>]

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 
>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 
>there is a descendent TListViewer, which is the only view related direct 
>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 
>know if TCluster and TGroup would remain as 'real' children but I am 
>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 
>hierarchy would have Object and View as parents and most other types 
>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 
>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 
>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.

-- 
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.