From: Marty K. <mrk...@co...> - 2012-12-18 22:49:23
|
On 12/18/2012 05:45 AM, White, Greg wrote: > Marty, Marty, can you comment on the impact on efficiency that Ben's approach implies. > > Seems to me even comparing only introspection interfaces implies a recursive descent. I > want to be sure we really get a clear advantage. The equality test could be optimized by first testing to see if the two structures are the same object and only start the recursive descent if that test fails. But do we need an test for equality? What are the use cases? Maybe pvAccess could use it to prune duplicate Structures? I will let Matej answer this question. > So far I see only a minor > inconvenience to the end user developer, of having to create a bit more code in order > to prepare their data before final packaging and sending. The disadvantage is > the potential that the application layer of the network would have to do a lot more > checking. Also, when would the checking be done? You wouldn't want to do it every time > a service interface is called, so the checking would have to be documented with a pattern > that avoided the possibility that a programmer inadvertently wrote code that checked the > type equality on every exchange instance. Even if we implement equality I would not give up the present semantics of StructureArray and PVStructureArray It is just as easy to use as other methods of creating a PVStructure that is an element of a PVStructureArray Marty > > Cheers > Greg > > On Dec 17, 2012, at 4:34 PM, Benjamin Franksen <ben...@he...> wrote: > >> On Monday, December 17, 2012 06:09:54 you wrote: >>> Wouldn't it be really really hard to define equality for pvData? >> Note I am talking about equality for the /types/ not the data. For these it is >> not hard at all. The only question that does not have an immediately obvious >> answer is when two structures types are equal: one might wish to identify two >> structure types that differ only w.r.t. the order of their members. However, >> this has been decided implicitly by the existing APIs: since you /can/ observe >> the original order, and since the BitSet-based optimization of data transfer >> relies on this order, there is no longer any choice: the order matters. >>> Wouldn't >>> any effort to do so be immediately bogged down in semantics? >> Deciding the semantics is the most important part of the design! If you shy >> away from that, your APIs are not well-defined. This merely post-pones the >> discussion to the point when someone uses the API and starts asking questions, >> such as happened now (see David's original message). >> >> I would have preferred to spell out this decision at an earlier point in time, >> so that we have this clear and in the open. >> >>> What would be your definition for equality? >> Structural equality. This is the only sensible equality since (as I noted >> above) all internal members are observable and code relies on that. To spell >> this out: >> >> field: equal if fieldType (the enumeration) is equal and the types are equal >> after downcasting >> scalar: equal iff scalar type (the enumeration) is equal >> (scalar or structure) array: equal iff array element types are equal >> structure: equal iff names and types of immediate subfields are equal if >> compared element by element (in the specified order) >> >> Cheers >> Ben >> >>> On Dec 17, 2012, at 2:15 PM, Benjamin Franksen <benjamin.franksen@helmholtz- >> berlin.de> wrote: >>>> On Friday, December 14, 2012 16:54:32 Marty Kraimer wrote: >>>>> On 12/13/2012 12:24 PM, dav...@di... wrote: >>>>>> I've just found an interesting (and slightly surprising) feature of >>>>>> PVStructureArrays. If you attempt to put to them then the put >>>>>> implementation performs a check that for for each PVStructure that you >>>>>> attempt to place in the array its structure is compatible with the >>>>>> PVStructureArray. But for both Java and C++ the compatibility check is >>>>>> that the references or smart pointers are equal. So, for example, if >>>>>> you construct two instances of structure, one for the PVStructureArray >>>>>> and one for a PVStructure you intend to put in it, the put will throw >>>>>> an exception, even if the structures are in all reasonable sense equal >>>>>> (same ID, same field names and equal subfields). >>>>>> >>>>>> I don't know of a good reason to do it this way, but assuming there is >>>>>> one this feature should be carefully documented (there isn't any >>>>>> mention of this exception in the documentation). Personally, if it's >>>>>> possible I would check for equality rather than identity. For >>>>>> efficiency you can always check identity first. >>>>> When creating a new array element of a PVStructureArray the >>>>> introspection interface MUST what is returned by >>>>> PVStructureArray::getStructureArray() >>>>> >>>>> This is documented. >>>>> >>>>> In the doc for PVStructureArray. >>>>> >>>>> getStructureArray >>>>> >>>>> Get the introspection interface shared by each element. >>>>> >>>>> In the doc for PVDataCreate. >>>>> >>>>> createPVStructureArray >>>>> >>>>> Create a PVStructureArray. It must be passed a structureToClone. >>>>> >>>>> This will become the Structure interface for ALL elements of the >>>>> PVStructureArray. It MUST be used to create any new array elements. >>>> Documented or not, this is wrong. You can and should define equality on >>>> PVData types. Correctness must come first, optimization can be added >>>> later as indicated by David. >>>> >>>> Cheers >>>> -- >>>> Ben Franksen >>>> () ascii ribbon campaign - against html e-mail >>>> /\ www.asciiribbon.org - against proprietary attachments >>>> >>>> >>>> ________________________________ >>>> >>>> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH >>>> >>>> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher >>>> Forschungszentren e.V. >>>> >>>> Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. >>>> Vorsitzende Dr. Beatrix Vierkorn-Rudolph Geschäftsführung: Prof. Dr. Anke >>>> Rita Kaysser-Pyzalla, Thomas Frederking >>>> >>>> Sitz Berlin, AG Charlottenburg, 89 HRB 5583 >>>> >>>> Postadresse: >>>> Hahn-Meitner-Platz 1 >>>> D-14109 Berlin >>>> >>>> http://www.helmholtz-berlin.de >>>> >>>> -------------------------------------------------------------------------- >>>> ---- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>>> Remotely access PCs and mobile devices and provide instant support >>>> Improve your efficiency, and focus on delivering more value-add services >>>> Discover what IT Professionals Know. Rescue delivers >>>> http://p.sf.net/sfu/logmein_12329d2d >> -- >> Ben Franksen >> () ascii ribbon campaign - against html e-mail >> /\ www.asciiribbon.org - against proprietary attachments >> >> ________________________________ >> >> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH >> >> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. >> >> Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph >> Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking >> >> Sitz Berlin, AG Charlottenburg, 89 HRB 5583 >> >> Postadresse: >> Hahn-Meitner-Platz 1 >> D-14109 Berlin >> >> http://www.helmholtz-berlin.de >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d > |