From: Benjamin F. <ben...@be...> - 2010-04-19 13:40:52
|
On Monday 19 April 2010, Marty Kraimer wrote: > Benjamin Franksen wrote: > > I also see that the methods getFieldOffset and getNextFieldOffset > > of PVField seem to depend on this knowledge of a field about where in > > the hierarchy it resides. > > Note that BasePVStructure and AbstractPVField implement these methods. > AbstractPVField has private fields > > private int fieldOffset; > private int nextFieldOffset; > > During creation these fields are computed. Thus the methods > getFieldOffset, getNextFieldOffset, and getNumberFields are very > efficent. And also use up lots of memory. I can see your point (elaborated in your other message) that this is partly balanced by needing less fields. Anyway, may main point is that even if for some reason this operation has to be as efficient as possible, it can as well be cached in the parent structure. > > Anyway, this part of the pvData design looks questionable to me. I > > would have expected structural information to be something that the > > parent (if any) and only the parent should know and be asked about, > > rather than the field. In fact, I cannot see any good reason for the > > getParent method. Correct me if I am wrong, but it seems that in order > > to get hold of a PVField, client code ultimately has to start traversal > > at some top-level structure. So it could as well remember (references > > to) the ancestors it encounters on the way. Embedding structural > > information into fields means that a field is much more tightly coupled > > to its containing structure than necessary, which is, I think, > > something one tries to avoid nowadays. (For instance, weren't iterators > > introduced just to avoid such a tight coupling?) However, as I don't > > yet fully grasp the whole picture, there may be deeper reasons for this > > decision, in which case I'd like to hear about them. > > Look at some support code in the javaIOC and I think you will see the > need for getParent. > > Support can optionally be attached to any field instance. For example > consider the following which is an analog input example > > <record recordName = "ai"> > <scalar name = "value" scalarType = "double" /> > <structure name = "alarm" extends = "alarm" /> > <structure name = "timeStamp" extends = "timeStamp" /> > <structure name = "input" extends = "linearConvertInput"> > <structure name = "linearConvert"> > <scalar name = "deviceHigh">2047</scalar> > <scalar name = "deviceLow">-2048</scalar> > <scalar name = "engUnitsLow">0.0</scalar> > <scalar name = "engUnitsHigh">10.0</scalar> > </structure> > <structure name = "input" extends = "caInputLink"> > <scalar name = "pvname">aiRaw</scalar> > <scalar name = "process">false</scalar> > <scalar name = "request" scalarType = "string" > > >value,alarm</scalar> > > </structure> > </structure> > </record> > > Read the javadoc under javaIOC/src/org/epics/ioc/support/package.html > and the other packages under support for details but for now let me give > a brief description about what happens. > > When record ai is processed the following happens: > > alarm and timeStamp are handled by support that I will not discuss now. > There are lower level alarm fields which I will also not discuss here. > > > The support attached to ai.input.input is called. It gets an integer > value and puts it in ai.value > The support attached to ai.input.linearConvert is called. It does the > linear conversion from ai.input.value and puts the result into ai.value. > Each of these supports calls getParent to locate the fields it needs. > > caInputLink looks for getParent().getSubField("value") which is > ai.input.value > > linearConvert looks for getParent().getSubField("value") which is > ai.input.value AND looks for > getParent().getParent().getSubField("value") which is ai.value. > > > When support is created it is given the PVStructure for the field to > which it is attached. It uses introspection to locate the fields it > requires. I am not convinced. First, all you say above can be realized without permanently storing the parent in the structure. Support can get the parent as argument whenever it gets called. Asynchronous support might need to store references to relevant parent fields; but synchronous support has no need for this. Second, even if for some other reason it were necessary to permanently store the parent in the structure, this applies to fields of structure type only. So we could at least move these methods from PVField to PVStructure. Cheers Ben |