From: Marty K. <mrk...@co...> - 2010-04-19 10:17:30
|
Benjamin, I am answering this message before the previous two message you sent because it is easier to answer quickly. I will answer the other messages later. Benjamin Franksen wrote: > PvData offers arrays but restricts them to scalar elements. I can understand > that you don't want arrays of arrays (i.e. multi-dimensional arrays) as they > can be built from simple one-dimensional arrays, using a structure with a > single subfield of array type for the data. > > OTOH, the only way I can see how to build an array of structures from the > existing interfaces is to represent an array of S (where S is a structure) > as a single structure containing multiple arrays, one for each field in the > structure S. I guess doing this transformation manually would be extremely > awkward in practice, especially if S contains sub-structures. > > In case it is not clear why I think arrays of structure are essential, > consider links (supposing that the concept of links survives the 3->4 > transition at all). I guess links are to be implemented as structures. I > would have found it very useful to have a variable -- or at least > configurable -- number of e.g. forward links. > > Is there a rationale to be found somewhere that explains why pvData allows > only arrays of scalars? > > You are not the only one making a request for arrays of structures. In fact support is currently being developed. The development is on a CVS branch copyMonitorChanges. The branch was created for changes that allow monitor options per-field rather that just for a record but we are also adding support for structure arrays. The branch exists for pvData, CAJv4, and javaIOC. If you do look at it realize that it is a work in progress. We hope to be able to merge soon. I hope by the end of this month. Earlier versions of javaIOC did allow arrays of structures and arrays of arrays. The support was removed because it was causing major problems. A simple example will show the problem: Suppose we have the following structure of fields: top xxx which is an array of structures [0] value ... [1] value ... A client was allowed to connect to top.xxx[1].value Also each element of xxx could have a completely different Structure defining the set of fields in the structure. Now what happens if structure top[1] is replaced by another structure or the length of top is set to 1? This was really a mess. All kinds of problems arose. When it became clear that there was a BIG demand for arrays of structures Matej and I had several Email discussions about what to do. The solution we decided on was to implement PVStructureArray BUT make it a leaf field. Thus a client can attach to top.xxx BUT not directly to subfields within top.xxx. Also there is a single introspection interface for the elements of top.xxx. This allows the convenience of an array of structures without implementation nightmares. Marty |