Re: Standard Ada Preprocessor

[Marin David Condic <nobody@noplace.com>]

I don't think I've ever said that it was "bad" to localize dependencies 
and try to isolate this stuff. Quite the contrary. But if you could 
scatter system dependencies all over the code or scatter conditional 
compilation all over the code, why couldn't it be done all over the 
whole system, just at the file level? Why couldn't a project of 100 
files have 50 for one system and 50 for another system and not have 
anything "localized" in that sense? So my contention is that it can be 
abused no matter where you push the problem.

Often system dependencies are *not* isolated - people write code all the 
time that works for only one system. Good, bad or somewhere in between - 
its still done. Offering some kind of conditional compilation doesn't 
really change that much.

That said, I'd be inclined to agree that perhaps the problem could be 
solved with some portable means of selecting different bodies for a 
build. Its a reasonable compromise that at least tends to encourage 
isolation of dependencies at some appropriate level. I don't know that 
it solves *every* problem, but it probably fixes enough of them that the 
rest wouldn't matter much.

Remember that one of the big strengths of Ada is its assistance on 
making *portable* code by providing strong *standard* mechanisims for 
dealing with system dependencies. Everything from specifying numeric 
accuracy up through tasking is an attempt to say "If the implementation 
is compliant to the standard, you go compile for the platform and your 
code will work." Providing a mechanism for dealing with compile-time 
dependencies is just going down that same path a little further.


MDC

Jeffrey Carter wrote:
> 
> There's a general SW engineering principle called localization. You 
> don't lump your code for dealing with a 4-line LCD display in with the 
> code for dealing with a temperature sensor just because they're both 
> hardware. Similarly, you shouldn't want your code for doing something 
> platform dependent on one platform lumped in with your code for another 
> platform, nor your code for doing things lumped in with your code for 
> deciding which code to use for this build.
> 
> Separating concerns this way makes everything easier to understand. I 
> can look at the code for dealing with a VMS file system without having 
> to understand the code for selecting a VMS file system; I can look at 
> the code for selecting the file system without having to look at the 
> code for dealing with file systems.
> 
> That said, it would be nice to have a standard, portable way to select 
> different bodies for a build, but even without it, the advantages of 
> separating these independent concerns seem clear.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================