From: David R. Quarrie <quarrie@vader.lbl.gov>
Date: Fri, 23 Jun 95 16:01:26 -0700
To: Jim Linnemann at MSU (517)355-3328 <LINNEMANN@jiml.pa.msu.edu>

Jim,

OK, I've just sent you a bunch of files via email. You should be  
receiving:

	corba.ps                
                [includes out of date idl syntax definition]
	colias.idl
	colias.f90stub.f90
	colias.ccstub.hh
	colias.ccstub.cc
	
The colias.idl file describes the existing BaBar data model. It  
cheats a bit since F_Node should be in module farfalla instead of  
colias, but my code generator expects that for module, class there  
is a .hh file of the form "module/class.hh", and that doesn't exist  
within farfalla for F_Node. It was just easier for me to add the  
relevant .hh file to colias.


The .hh file is the interface definition file and  
has to be included in client implementation files. For the  
ccstub.hh file, it's the declaration of the C (not C++ actually)  
routines that are defined in the ccstub.cc file. These are glue  
routines that forward the calls to the appropriate C++ object  
function members. The .hh file includes a bunch of other .hh files  
(e.g. colias/F_Node.hh). These .hh files are the interface  
definitions for the classes. Somewhat confusingly, in C++ you have  
to specify both the public and private interface in the .hh file -  
pretty silly really.

The other files get generated automatically from the .idl file.

> I was     imagining 
> someone at FNAL say adding automatic generation     of I/O
> routines to Farfalla, or emitting them via extensions to the
> IDL     compiler...

Sounds good to me. I'm happy to go along with that concept. One  
problem with the automatic generation of the I/O routines from the  
IDL interface is that that interface only specifies the public  
interface via accessor functions. It says nothing at all about the  
internal data members, only how they are accessed. Thus it doesn't  
deal with any bit packing or other fancy operations (e.g. you might  
return the module & channel ids as longs, but they might in fact be  
packed fields within the data member. IDL won't specify that.

>     By the way, to the extent that Farfalla nodes have nicely
> hidden dynamic allocation/deallocation from such as myself,
> I'm surprised one wouldn't try to have classes inherit that
> from them, rather than creating the objects from scratch and
> then copying them into nodes later?  Perhaps I am in the old
> ZEBRA philosophy of everything is eligible to be written
> unless forcibly dropped...
>

Basically, that's the approach we're sort of taking. Most of the  
"temporary" objects do in fact inherit from F_Node (actually  
DATColiasNode) so they are elligable for output.

Finally, here's a trivial F-90 subroutine that accesses data within  
an event:

	David

    SUBROUTINE f90_event( handle )
    USE colias_module
    IMPLICIT NONE
    TYPE(F_Node_handle), INTENT(IN) :: handle
    TYPE(F_Node_handle), POINTER :: rawNode
    TYPE(F_Node_handle), POINTER :: svtNode
    TYPE(DATSVTRawNode_handle), POINTER :: svtRaw
    TYPE(DATSVTDigi_handle), POINTER :: aDigi
    TYPE(DATSVTDigi) :: bDigi
    INTEGER :: nDigis, index
    rawNode => F_Node_getChild( handle, DATRawDataNode_type, 0 )
    svtNode => F_Node_getChild( rawNode, DATSVTRawNode_type, 0 )
    svtRaw  => DATSVTRawNode_from_F_Node( svtNode )
    nDigis   =  DATSVTRawNode_nDigis( svtRaw )
    PRINT *,"nDigis=",nDigis
    DO index = 1, nDigis
	aDigi => DATSVTRawNode_digi( svtRaw, index-1 )
	PRINT *,"Digi ", index
	PRINT *,"  aDigi.channel ", DATSVTDigi_channel( aDigi )
	CALL DATSVTDigi_toF90( aDigi, bDigi )
	PRINT *,"  bDigi.channel ", bDigi % channel
    END DO
    RETURN
    END