Re: Full view of a private partial view cannot be a subtype

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

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:43498b2a-773c-454a-b0e7-ade5d6594bd4@googlegroups.com...
...
>Besides UIs, the one problem that springs immediately to mind is the 
>internals of a
>compiler's IR/parse-tree.

I can speak to this (at least somewhat), and I think the full OOP version 
would be a nightmare.

Janus/Ada (originally designed in the early 1980s, before there was such a 
thing as type extension) uses variant records controlled by enumeration 
discriminants. That is a very effective organization in Ada, because of two 
features of Ada not found in most other languages - case completeness and 
variant component checks.

Case completeness means that adding/removing a variant is relatively easy: 
most case statements that need changing are called out by the compiler. Time 
has proven that it isn't even worth looking for change locations since the 
compiler will point them out much quicker than one can find them. Similarly, 
adding/removing/moving/modifying components in the variant either cause 
compiler errors (see above) or runtime errors from accessing non-existent 
components. With good testing (easy for an Ada compiler - the ACATS provides 
the needed foundation), the runtime errors will point out the majority of 
other changes needed. Indeed, I've been introducing additional variants into 
the Janus/Ada data structures in order to get even more advantage from these 
features -- they eliminate large amounts of debugging that would otherwise 
been necessary.

I've never tried an OOP compiler tree, but the Claw Builder uses an OOP 
organization both for the GUI and for the code generation. And that did not 
really work out well. There is so much boilerplate that has to be 
constructed for every new widget type (to declare all of the overriding 
routines, to provide basic implementations for those routines, and the like) 
that there is a strong dis-incentive to adding new widgets. (The last time I 
tried to add a widget, it took over 2 days solid coding to get to a 
compilable type.) And the boilerplate didn't seem (for Ada) to make anything 
easier to implement or debug.

Similarly, adding a new kind of code generation (something that happens 
frequently with the Builder, probably would happen fairly often for a 
compiler as well) is a nightmare, as the new dispatching routine has to be 
added to every existing widget.

By abandoning traditional OOP, one could do a bit better (especially by 
implementing many concrete operations in the root classes -- meaning, in Ada 
terms, that they can't be interfaces), and maybe some of the boilerplate 
could be reduced - but to do so, you'd have to introduce even more 
operations. The number of dispatching operations alone was becoming 
daunting.

Thus, I'm unconvinced that a compiler data structure would be any advantage 
written in OOP (at least, if the "conventional" version was written in Ada). 
I suspect the reason that OOP held some much advantage to many programmers 
(read, C programmers) is that they had a language which provided no help at 
all for "conventional" programming, while Ada already had information 
hiding, true privacy, case completeness, variant component checks, array 
index checks, etc. So the increment is so much less.

I think the only place OOP really holds an advantage is for programs based 
around call-backs (like most GUIs). And I think you'd be nuts to use 
call-backs if you don't have to, so there isn't much need for OOP (assuming 
it is compared to "conventional" Ada and some some other language that lets 
one do anything, no matter how unintended).

                                                 Randy.