Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Mon, 12 Sep 2005 14:26:41 -0400

Hi Marty:

On Sep 9, 2005, at 11:51, Marty Kraimer wrote:

... "CS Office Data Access Layer" ...

Although part of the name is "Data Access", this proposal is a

layer that will interface to EPICS (V3 and V4), TINE, TANGO, ACD,

and DOOOCS and is not the same as dataAccess.

Right, it's not the same, but since it's only in its beginnings,
there's a good chance that the V4 method of describing data
turns into the "CS office" API for describing data.

I think this means that V4 needs to include a generic type description
interface ala EpicsDataDescriptor.

I also understand that a EPICS V4 database implementation is easier
to do with a  list of BasicType/DbfType enums.

Does it make sense to offer both?
Can the data interface that one gets from EPICS V4 include
    BasicType getBasicType();
but also getDataCharacter()  [ boolen, integer, real, ...],
getBitsize(), ...
The "CS Office" people can then choose to ignore the BasicType,
because that one won't include the TINE-specific tuple type.

"Should there be a major distinction between primitive and compound

types"

...

EpicsDataReader has methods for getting any EpicsDataCharacter

data. Many of the methods will have very strange semantics if

applied to particular types. Also it will need many methods.

You're right. There's the choice between many individual readers,
each only offering the few specific accessors,
or very few -- if not one -- readers with many accessors and
semantics hidden in comments and exceptions:
"// Will throw .... unless data is actually of type ..."

Each Java object has a getClass(),
and each class has a getDeclaredFields() method for looking
at all the fields, and then the Field interface
handles all types:

  getClass()   ... gives the type of this field, in case you care
  getDouble()  ... tries to give value of field as double,
                   or throws IllegalArgumentException
  getLong()    ... long ...
  toString()   ... string ...

Java JDBC for relational databases:

The one and only "ResultSet" interface offers getString(), getLong(),

getDate(), ...

If you don't check the type and happen to call the wrong getXX(),
you get an exception.

So I see a trend towards one-accessor-fits-all,
but maybe I'm looking in the wrong places.

In the long run, the end user effort is similar:
To handle all types, you have to write code that handles all types.
But with a single accessor you can start out easy,
only invoke "toString()" on any result.
It'll compile and run with any data.
Then you add handling for "getDouble()" etc.

Thanks,
-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System