Code organization

[NiGHTS <nights@unku.us>]

When I programmed in C, code organization was very easy. If my code file became too long and complex, I'd simply create new files and separate out code organized in some way. Then I would #include the C files into my main.

In Ada, I've attempted to build packages so that more code can be distributed into organized categories, but that only gets me so far.

In one instance, I have a package that handles an xhtml object, but it has tons of interface functions and procedures to the object the package encapsulates. In this case I am frustrated by the ever-growing size of this source code. The procedures themselves may be grouped into categories, so it would have been nice to move some of these procedure bodies to other files.

In another instance, I have two nested tasks, and the inner task has a number of local functions and objects it uses. With all this spec stuff living inside the declarative areas deep in the body of my code, I would rather organize them in another file, but I don't want to change my code to work with task access pointers (I've tried this and there were problems, so I've had to keep the code there). In this case, or in any case where there is a declarative region with private scope specs, I wonder if there is any way to move code out of the body and into another file.

Essentially the biggest hindrance is the rules of visibility. A procedure or task created inside the body of another one has full visibility of the variables within its scope. If it were possible to move the code somewhere else, I feel like Ada would complain that it can't see those local variables. And if we go the route of outside procedures being passed tons of "in out" to these local variables, then we'd have to also expose their types which may also have been created within a local scope. Many times we need access to a local procedure, so then I'd have to add an anonymous access procedure as a parameter just so it can work with it. At this point, what would have been a simple little utility procedure call has become a monster of parameters that makes the implementation very difficult to read.

I don't think there is anything I can really do other than find creative ways to create more packages, but doing so many times means writing more code to manage the extra packages, memory access, and visibility contexts.

Any thoughts on this?