RJLRef: $PH/05s523/gencppVsChgenProjectInfo.txt 
(was $PH/05s523/gencppOrChgenProject.txt)
(linked from 06f522)

Contents: 
1. Assignment 2 Comparisons
2. What is OOP? 
3. Supporting evolutiion of BDE
4. 05s523's BDE Upgrade project


1. Assignment 2 Comparisons

This note was inspired by MMallikaluri's Assignment 2
which is the first one I received in 05s523.
[Ref:  $PH/05s523/05s523BDE2GENAsgntDue050311.txt]

Her report was effective and I hope assignment 2 will help 
others understand how some chgen and gencpp features and 
options (-log and -DUSE_STL) can be used in future projects.

In retrospect I wish gencpp had used the USE_STL option to generate
two distinct code libraries, not one version with conditional 
compilation inside each method of STL or intrusive linkages. 
The fine-grain interleaving of the two makes their comparison easy;
generating two separate code versions would have risked
wider disparity between the two versions, and more trouble 
when porting bde to gencpp. So gencpp's output  favors comparison 
and compatibility over simplcity and future maintenance.


2. What is OOP?

Mallika's quote on gencpp vs. chgen:
"object-oriented programming with C++ vs structured programming with C"
raises a question though - 'What is OOP'?

Object-based Programming is a subset of Object-Oriented Programming, 
because it uses only encapsulation but not inheritance. GUI's require 
another advance - toward event-driven behavioral models, 
(coming next in this course). Distributed BDE, which supports 
collaborations like multi-person gaming also needs concurrent
transactions on a replicated database by extending log and replay 
features. So beyond OOP there is concurrent collaborative programming.

You might agree with me that XWindows is much more object-based
than bde, although X11 is implemented in C and bde started there.
Bde src and pr_util code originally worked in C on 32-bit VAX 
and Unix DEC-stations.

Neither X11 nor bde realy use the compiled-in inheritance of C++  
like modern GUIS do. BDE (and X11, I believe) use delegation instead,
using pointers to access separate 'superclass' objects.
But BDE's use of  delegation is limited by its data model 
which still has no inheritance relations. X11 is constrained to 'C'.

(Inheritance was first used in COOL-LCP JPsim and state models;
BdeSym project by HHuang and others added one superclass teXtBlock XB 
from project SymTxt, but XB did not make it into our BDE yet,]

[RJL060820: the bdecode project evolved toward bdesym on the main 
branch. (THis was a mistake: it should have been a side branch.)
Further bdecode progress was postponed and bde reverted back to 
pre-bde code that evolved separately to support bdelog/replay.
This was done along a side branch by sjanant and I. 
(With hindsight, this should have been done on the man branch.), 

Thanks to the 04f523 team which successfully accomplished the 
difficult code merge of this branch  back into the main trunk 
of bdei. THey also updated chgen to $PH/COOL-GEN/gen/ver_13,
which generated thousands of changed lines in bde/pr_util/. ]


3. Supporting evolutiion of BDE::

X11 is a GUI provider library and pr_util is a database
provider library, and BDE is a 'user' of both of them. 
Chgen or gencpp provides database access, 
and X11 provides the GUI menus  and canvas.
Inside the drawing canvas 'widget', bde does its own graphic 
calculations (geometry and button-event management),
and the local X11 server does line--drawing, text aquisition and rendering. 

Gencpp has a more O-O data model than chgen for database access,
but gencpp could interpret schema.msdat to generate stream I/O 
which would probably simplify code generation considerably.

BDE would be improved, maintenance and stability-wise, 
by more use of (single) inheritance inside the canvas:
e.g., by generalizing its data model to the second one in
        $PH/COOL-BDE/bdeUG_2000/bdeUG_2000.ppt (slide #15).

This new model shares canvas drawing code for shapes and 
for text rendering among nodes, links and  captions. 
This does not depend on using gencpp, but rather on upgrading 
chgen so it produces reliable code on linux and alpha hosts 
regardless of (not just in the absence of) evolutionary changes
to bde's schema.sch file. 


4. 05s523's BDE Upgrade project

The design choice which is hardest to make is whether it is 
easier to adapt bde/src to gencpp' pr_util 
or to adapt chgen to bde/pr_util's changes. Gencpp has more modern
C++ code but was held back by the desire for compatibility with
gencpp's  pr_util API interface that BDE could continue to use 
without any or  with minimal code changes.

Two risks of converting bde to gencpp now are: 

(1) gencpp is new and untested and probably less stable than chgen.
(2) gencpp could provide better access methods but this changes 
pr_util's interface and requires code changes in bde/src.

This is my rationale for desiring to upgrade chgen to produce  
$RL/bde/pr_util. Then bde would work with chgen while we extend its 
data model and later upgrade both gencpp and bde to the extended 
data (class) model with an improved the O-O interface between them.