Re: Need advice re package organization.

[Stephen Leake <Stephe.Leake@nasa.gov>]

"Robert I. Eachus" <rieachus@attbi.com> 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