Re: Move location of fieldName from Field to Structure

[Marty K. <mrk...@co...>]

On 03/27/2012 07:25 PM, dav...@di... wrote:
> As discussed at the conference call I've written up the proposal for the move of fieldname from Field to structure.

The original proposal has:

public interface Structure extends Field{
      Field getField(String fieldName);
      int getFieldIndex(String fieldName);
      Field[] getFields();
      String getFieldName(int fieldIndex);
      String[] getFieldNames();
}

David proposes:


public interface MemberField {
      String getFieldName();
      Field getField();
      void toString(StringBuilder buf);
      void toString(StringBuilder buf,int indentLevel);
      String toString();
}

public interface Structure extends Field{
      MemberField getMemberField(String fieldName);
      int getFieldIndex(String fieldName);
      MemberField[] getMemberFields();
}



I will make two arguments in favor of the original proposal:

1) Less objects.

With the original the number of objects in a Structure  with N subfields 
is (immediate subfields only)

Structure 1
fieldNames 1 for array and N for each fieldName
fields 1 for array and N for each field.

Davids proposal has

Structure 1
memberFields 1 for array and N for each memberField
Each member has 1 fieldName and 1 field this 2N objects

This original has 3 + 2N objects
Davids has 2 + 3N objects

2) The original but has

  String[] getFieldNames();

This is very useful.

Marty


>
> It's essentially what I've suggested before, plus the getFieldName() method on PVField, and close to Marty's proposal, so I don't think it should take too long to look at.
>
> One thing looking at Marty's version is that it doesn't discuss how the changes affect the serilization of fields and the introspection API. Perhaps it's not been discussed so much because it's obvious to most people, but I've added how I think it affects things at the end. I'm imagining that it will be the same for Marty's proposal since there similar.
>
> Marty do you agree with my assessment of the serialization and introspection registry changes?

Matej is responsible for serialization/deserialization.

Marty
> Greg/Bob -  would you prefer into Marty's doc or kept as a separate document?
>
> Thanks,
>
> Dave.
> ________________________________________
> From: dav...@di... [dav...@di...]
> Sent: 27 March 2012 16:46
> To: epi...@li...
> Subject: RE: Move location of fieldName from Field to Structure
>
> As promised I've attempted to explain more fully what I said in last week's conference call about the refactor of pvData, moving the fieldname from field to structure.
>
> Previously I'd suggested that the current location of the fieldname in the Field object was not the best place for it and a possible a way of refactoring the Field hierarchy to move the fieldname into the structure, which I anticipated would also require a similar refactoring of the PVField hierarchy, with some of the logic occuring one level higher (e.g. in the PVStructure rather than in the PVFields in a PVStructure) in the same that the fieldnames have moved up into the structure in the field hierarchy.
>
> Marty suggested a different refactor of the Field hierarchy, which after some revision ended up being fairly similar to my suggestion. The PVFields would also have a getFieldName() (I think this was Andrew's suggestion) instead of the more substantial change I was thinking of.
>
> Since Marty was now considering a change I quickly put together a further, slightly more detailed, suggestion of how to refactor the field hierarchy, how the serialization protocol would change and a tentative suggestion of how the PVFields might change as well. I initially wasn't convinced of the value of refactoring the Field hierarchy without doing the more substantial refactor of the PVField hierarchy.
>
> What I was attempting to explain last week was that I'd had another look at this and come to the following conclusions.
>
> 1) Refactoring the Field hierarchy is relatively straightforward, whether via Marty's suggestion or mine,  (by no means a trivial job, but doable). The two methods require about the same amount of work, in slightly different places.
> 2) The more substantial refactoring of the PVField hierarchy is much harder than the field hierarchy, since a lot of code is dependent on PVFields knowing their own names.
> 3) It's possible to do the field hierarchy refactor without a substantial refactor of the PVField hierarchy using the getFieldName() method along the lines that have been suggested. This is equally true of both Marty's and my suggested refactor, since in both cases the Structure contains the same information (names + fields).
> 4) I think there is value in refactoring the Field hierarchy without making a correspondingly substantial change to the PVField hierarchy, especially if the serialization protocol is correspondingly changed, the introspection registry works on 'type' rather than 'type' + name and the construction interfaces are cleaned up, e.g. the superfluous string in the PVStructureArrays disappear.
>
> This was what I was trying to express last week in the call and in the minutes:
>
> "structures should consist of members which consist of name plus  a type object. This isn't inconsistent with PVs knowing their own name."
>
>   but it's hard to write that up quickly in a conference call.
>
> I've been able to look a bit more at refactoring the Fields hierarchy. I'll write that up now and send that out soon. I didn't manage to come up with a design for refactoring the PVField hierarchy. I'm still think that this would have been the ideal design if we were starting from scratch, but pvData just hasn't been designed that way and it would be a lot of work for not a huge gain. However there may be some places where it does make sense to move some of the logic in the PVField hierarchy up one level and where it's easy to do.
>
> Regards,
>
> Dave.
>
>
>
> Dr David  Hickin
> Software Systems Engineer (EPICS)
> Diamond Light Source Ltd
> Diamond House
> Harwell Science&  Innovation Campus
> Didcot, Oxfordshire, OX11 0DE
>
> --
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
> --
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure