Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Mon, 21 Feb 2005 10:56:32 -0600

Benjamin Franksen wrote:

On Friday 18 February 2005 18:12, you wrote:

I have again updated dbd.html which is available via

http://www.aps.anl.gov/asd/people/mrk/epics/base/V4

Hi Marty,

one comment regarding the epicsTypes document and a proposal for an additional

structured data type.

First, I don't understand why every library is specified as as a structure of

function pointers ("interface"). IMO, this only makes sense if you anticipate

the interface to be passed as an argument, because there might be different

implementations of the same interface. If all you ever use is one and the

same global pXYZInterface, then all this gives you is the run-time overhead

caused by the additional level of indirection.

One reason is that the epicsShare nightmare almost goes away. Instead of

epicsShareFunc <type> epicsShareAPI xxxFunc(...

for every function in a library . By using an interface there is just

one definition such as

epicsShareExtern asynManager *pasynManager;

Another reason is "Everything is an interface" seems like a good idea.

Note that most interfaces will have multiple implementations just like

for asynDriver.

A comment about using C++ instead of C. This could all be done in C++

using pure abstract classes. But when I think about the syntax, the C++

version looks worse (at least to me) than the C version with one exception.

C forces the definition

typedef struct <someInterface> {
   <type> (*method)(<args>);
  ...

Rather than

struct <someInterface> {
   <type> method(<args>);
  ...

Other than that the C++ syntax is more verbose than C.

Second point. As a more general observation, much of what I read in the above

documents reminds me of inventing yet another (domain specific) programming

language. Only that it is not for programming, but restricted to data

specification (no way to define functions or routines). The latter is

expected to be done in a separate language (C, sometimes SNL). Although the

data model is strongly influenced by what is available in C, it is still hard

to come up with good generic routines to handle this data in C. This is no

wonder, given that C is not very powerful when it comes to genericity.

But I digress. What I want to point out is that there is one very useful thing

missing from the data model, namely algebraic data types, a.k.a. tagged

unions. A syntax could look like this

union(name) {
	choice(choice_name,"choice_value",choice_data)
}

where 'choice_data' can be any valid data type, including struct or another

union. Thus, menu would be the special case where the 'choice_data' is void

(or null; another basic data type to be added).

Let me give an example where I missed the possibility to define such a data

type: When lately I wrote a general conversion record, I would have liked to

define something similar to the following:

union(convSpec) {
   choice(convLinear,"Linear",linearConvSpec)
   choice(conv1DTable,"1D Table",tableConvSpec)
   choice(conv2DTable,"2D Table",tableConvSpec)
   choice(convSubroutine,"Subroutine",subroutineConvSpec)
}

struct(linearConvSpec) {
   field(offset,DBF_DOUBLE)
   field(slope,DBF_DOUBLE)
}

struct(tableConvSpec) {
   field(name,DBF_STRING)
   field(directory,DBF_STRING)
}

struct(subroutineConvSpec) {
   field(name,DBF_STRING)
}

Even with your extended V4 dbd language I could not do this, but had to split

the conversion specification to many fields. This raises many problems, for

instance: since there is no atomic update(*) of the whole conversion spec,

when is the update complete and to be acted upon? No way to know, other than

introduce yet another field as a trigger. Record support code becomes

unnecessarily complicated. Furthermore, each specification field must be

duplicated, in order to save the current values while new values are in the

process of being set. Etc. etc.

Andrew also suggested a union.

JAVA does not have a union. Will this cause us any problems?

Marty

Cheers,
Ben

(*) I understand that EPICS V4 will provide some method to atomically update

structured record fields.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System