Re: EPICS base V4: iocCore database

[Marty Kraimer <mrk@aps.anl.gov>]

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.
>
>