Re: Derived private interface

["Randy Brukardt" <randy@rrsoftware.com>]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:j0nmqd$voi$1@tornado.tornevall.net...
> On 07/26/2011 02:04 PM, Randy Brukardt wrote:
...
> and record_definition includes "null record", so these are all extensions 
> and
> examples of programming by extension. I wouldn't have thought that I'd 
> have to
> define what I meant when using an Ada term with you.

I wasn't thinking of it as an Ada term. My mistake.

>> Others have pointed out that using case statements as you suggested is
>> essentially worthless unless you know every entity that the program is 
>> going
>> to process before the fact. And real world programs are not like that (I 
>> have
>> plenty of experience changing hundreds of case statements each time we 
>> make a
>> change in node types or intermediate code definitions in Janus/Ada).
>
> Yes, it's called "design", and it's part of what distinguishes S/W 
> engineers
> from coders. As you note, it's an iterative process. The extra work and 
> extra
> code is worth it for the significant improvement in ease of reading and
> understanding that results.

I don't agree; the 30 page case statements found in our optimizer and some 
other parts of our compiler don't add anything to ease of reading! And there 
is no choice with case statements, you have to have a bunch of lines for 
each option; when there are literally hundreds of options there is no way to 
simplify.

And updating those cases typically takes about a week's work; it is so time 
consuming that we avoid making changes to the intermediate code if any 
workaround can be found even when that is the best solution to a problem.

Ada 2012 will help a tiny bit by providing useful set subtypes (even if they 
aren't called that), so at least it will be possible to give a name to 
groups of discontiguous enumerations and that will reduce the work in some 
cases.

I admit that dispatching takes a leap of faith ("it just works" when used 
properly), and not everyone seems to be able to understand it. But having a 
lot less code in the critical parts of the application should help 
understanding.

Note that OOP (at least in Ada) does not really provide an answer for the 
"it takes a week to modify" problem. The Claw Builder (a full OOP design) 
has a similar problem in the other dimension, in that defining all of the 
needed overrides also takes a week or so. And in neither case (OOP or 
non-OOP) is is usefully possible to do just part of the work (as an agile 
programmer such as myself would prefer) -- neither program will even compile 
until all of the overridings or case statements are defined. Either way, Ada 
makes it too hard to add new abstractions to an existing set.

                                                     Randy.