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,a270a1fc28d4f812 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-28 17:07:33 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: OOD in Ada? Date: Fri, 28 Jun 2002 19:08:08 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3d135676$0$8511$cc9e4d1f@news.dial.pipex.com> <3d1870b0$0$8507$cc9e4d1f@news.dial.pipex.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:26783 Date: 2002-06-28T19:08:08-05:00 List-Id: Fraser Wilson wrote in message ... >"David Crocker" writes: > >> There is no way I want to put all the expression and statement classes in >> one package! The natural way to construct the project is to put each class >> in its own file (and hence package, if I am using Ada). > >Put just the abstract base classes for Expressions and Statements in >the same package, and put derived classes in their own packages. You >could use child packages for this. > >My compiler is structured along these lines: > > package Trees; -- abstract base class for tree node > package Trees.Expressions; > package Trees.Expressions.Operators; > -- ... > package Trees.Statements; > package Trees.Statements.Ifs; > -- enzofoort > >You get the idea. If it turned out that expressions and statements >were mutually dependent, I would have either put them both in the same >package, or have only the package bodies rely on each other (which you >can do by casting down at run time -- not really recommended, but >nevertheless useful). This is a fine solution, but it runs into a problem in use: essentially every reference to anything will need a type conversion to the "real" type in order to access the operations/components. (This happens a lot in the Claw Builder, and it gets really old, especially in a "use"-adverse environment, because the type conversions make the code much harder to read.) That is why the ARG has spent so much time on the various proposals here, and finally appears to have settled on the "type stub" approach. Randy Brukardt