Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Tue, 12 Jul 2005 08:43:40 -0500

On Jul 12, 2005, at 8:10 AM, Benjamin Franksen wrote:

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.

Ok.

The following can be defined:

menu(invalidAction) {
   choice(invalidActionContinue_normally,"Continue normally")
   choice(invalidActionDon_t_drive_outputs,"Don't drive outputs")
   choice(invalidActionSet_output_to_IVOV,"Set output to IVOV")
}

struct(invalidOutput, type {
    field(invalidAction,menu(menuIvoa))
    field(invalidValue,Value)
}

And  then the record.dbd would be

   field(invalidOutput,struct(invalidOutput,float64))
   field(output,device(none,processInvalidOutput))

And the interface definittion becomes

Some .h file contains:

   class processInvalidOutput {

 virtual void compute(invalidOutput<epicsInt32>

&output,,epicsString &status, epicsInt16 &severity);

 virtual void compute(invalidOutput<epicsInt32>

&output,,epicsString &status, epicsInt16 &severity);

         ... // perhaps other types for value
   }

and the process method calls

pprocessInvalidOutput->compute(invalidOutput,,status,severity);

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