Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 12 Jul 2005 15:10:00 +0200

Marty,

(I tend to agree that DBD should not contain method descriptions, so I 
won't comment further on this issue.)

Your proposal nicely circumvents using type arguments for sub-structs. 
But then it does not (IMO) really solve the problem.

> The record.dbd file contains
>
> record(xxx)  extends iocRecord {
>     ...
>     field(invalidAction,menu(menuIvoa))
>     field(outputValue,float64)
>     field(invalidOutput,device(none,processInvalidOutput))
>     ...
> }

This is only slightly better than what we have nowadays. It is not 
clear, here, that there is a close interaction between the two fields 
'invalidAction' and 'invalidOutput' (other than by their name).

With this proposal, record types will still contain a myriad of single 
fields, without any structure. Furthermore, new record types may 
deviate from the naming pattern above, causing us problems similar to 
those we have today with slowly diverging record type definitions.

If we introduce type variables into the DBD language, we can group these 
fields together nicely. What we gain is more structure for record types 
instead of a flat array of single fields.

This gets even more important in those cases where a building block may 
be used more than once in the same record type. For instance, a record 
type may have more than one output (with possibly different value 
types) and may wish to configure invalidACtion and invalidOutput 
separately for each of its outputs.

>     class processInvalidOutput {
>          virtual void compute(int32 value, DbfMenu
> &invalid,epicsString &status, epicsInt16 &severity);
>           virtual void compute(float64 value, DbfMenu
> &invalid,epicsString &status, epicsInt16 &severity);
>           ... // perhaps other types for value
>     }
>

Ok, of course you can use overloading for dispatch on teh argument type. 
But this still causes code duplication. The interface is harder to 
understand with those many methods. It is also harder to maintain. The 
programmer of the invalidOutput module must provide code and interface 
routines for all types. Note, in my proposal there is /no/ restriction 
on the type argument (other than that it is a valid DBD field type). 
For instance, it could also be a struct type or an array or an arry of 
structs, or...

> The process routine then has a statement like
>
> pprocessInvalidOutput->compute(outputValue,invalidOutput,,status,seve
>rity);

So record support must bring together the otherwise unrelated fields.

All this falls a bit short of the original goal, which was to have a 
growing library of building blocks that can be plugged into new record 
types as a single field, so that (a) creating new record types is a lot 
easier than today, and (b) record types are no longer flat arrays of 
many (apparently unrelated) fields, but have structure and are thus 
easier to understand and maintain.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System