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,23cf9f1e93744eed X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-04 06:49:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!news.gtei.net!news-out.visi.com!petbe.visi.com!news.state.mn.us!arclight.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Need advice re package organization. Date: 04 Aug 2003 09:45:48 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.com> <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> <9d2Wa.301$jp.253@newsread4.news.pas.earthlink.net> <3F299920.9070603@attbi.com> <3F2AE64F.30309@attbi.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1060004835 7139 128.183.235.92 (4 Aug 2003 13:47:15 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 4 Aug 2003 13:47:15 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Xref: archiver1.google.com comp.lang.ada:41166 Date: 2003-08-04T13:47:15+00:00 List-Id: "Robert I. Eachus" writes: > Stephen Leake wrote: > > > The core tool is probably best written in Ada using ASIS; it would be > > somewhat similar to Auto_Text_IO. Emacs ada-mode and GPS could provide > > user interfaces to the tool, but it would really need to be run as > > part of the build process (from a makefile). > > Hmm. That would imply that the inquiry functions where in a child > > package; no problem if they don't need to be dispatching. > > You made me think for a while, but I came back to my original idea. > The problem with automatically generated non-dispatching inquiry > functions would be that, when overloading occurs, the user is going to > be really upset by the lack of a class-wide operation. The easiest > way to explain it is that inserting a type conversion to a specific > type would get the code to compile, but sometimes that conversion > would raise an exception at run-time. So, I don't see problems > occuring frequently, if your design is the more typical bushy Ada > style derivation tree, but I see them as nasty when they arise. > > So I think it is much better to have the inquiry functions in the > package which declares the type, which seems to rule out ASIS as a > generator, unless the ASIS package generated as set of inquiry > functions for the type and all types derived from it. I was a bit hasty. It's somewhat simpler to have ASIS generate a child package, but it can also provide a single package with the type and the inquiry functions. You just use it as a preprocessor. You write a "template" package that has the type but no inquiry functions, and the tool produces a new package that has both. It's up to the makefile to keep things straight. It would be nice if we could extend gnatmake to know about arbitrary preprocessors :). > This might require multiple child packages to be generated. A > typical inquiry function might look like: > > function Selling_Price (Stock_Item'Class) return Dollars; > > And the ASIS tool would have to generate explicit dispatching code in > the body, with the appropriate with clauses. Yech :). > I think that is probably overkill for inquiry functions, but it > might work well for things like creating a model-view-controller > environment with on screen display for things like bench testing > subsystems. The test environment could automatically be generated > from the software and a test script. (The test script would provide > the inputs and a list of the objects to be displayed.) People keep proposing these "automatically generated test environments". I find them un-helpful; the hard work is in the input data, and I find that Ada is an excellent language for generating input data; I don't want to use some weak "script" language. It is also easy to write a test environment in Ada. Maybe for GUI tools, things are different. I have some GUI test stuff in Windex, and it is a significantly different style than my other tests. But even there, the large majority of the code is about generating the right input events (positioning the mouse, clicking it, generating key events); the "test environment" is pretty thin. > > > -- > "As far as I'm concerned, war always means failure." -- Jacques > Chirac, President of France > "As far as France is concerned, you're right." -- Rush Limbaugh > -- -- Stephe