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
- Replies:
- Re: Record support and user-defined fields Benjamin Franksen
- References:
- V4 iocRecord: forward linking Ralph Lange
- Re: Record support and user-defined fields Benjamin Franksen
- Re: Record support and user-defined fields Marty Kraimer
- Re: Record support and user-defined fields Benjamin Franksen
- Navigate by Date:
- Prev:
Re: Record support and user-defined fields Benjamin Franksen
- Next:
Re: V4 Design: Record Processing Tim Mooney
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Record support and user-defined fields Benjamin Franksen
- Next:
Re: Record support and user-defined fields Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|