Cytoscape Wiki|
← Revision 1 as of 2005-10-03 21:27:26
Size: 400
Comment:
|
← Revision 2 as of 2005-10-04 14:36:28 →
Size: 1581
Comment: This issue is still very much open to debate...
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| RowanChristmas 10/03/05 -- A copy? or the actual CyData object? Getting a copy seems like it would be more or less useless as I would not be able to have my changes reflected anywhere. Also I am not sure what we gain by not having this class extend CyData/Definition directly. It seems like the logical way to go, especailly since both of those classes are already implemented by the same class. |
RowanChristmas - 10/03/05 -- A copy? or the actual {{{CyData}}} object? Getting a copy seems like it would be more or less useless as I would not be able to have my changes reflected anywhere. Also I am not sure what we gain by not having this class extend {{{CyData/Definition}}} directly. It seems like the logical way to go, especailly since both of those classes are already implemented by the same class. EthanCerami - 10/4/05 - This is still very much open to debate, and I don't think anyone agrees 100% with my original proposal to have {{{CyAttributes}}} return {{{CyData}}}. However, if we were to adopt this approach, I agree it would have to return the actual {{{CyData}}} object, and not a copy or a clone. Otherwise, things would get really confusing. And, I definitely see the logic in having {{{CyAttributes}}} extend {{{CyData}}} / {{{CyDefinition}}}. However, I think there is also some logic in having {{{CyAttributes}}} embed {{{CyData}}} too. My current thinking on this is that we rename {{{CyData}}} into something more meaningful, and more clearly tied to its role as a data structure. For example, we might consider renaming it to something like {{{SparseTree}}}. If that were the case, then we could simple say that {{{CyAttributes}}} uses a {{{SparseTree}}} as a back-end data structure, and {{{CyAttributes}}} provides simplified access to that data structure. If you want to add data that is any more complicated, you can obtain the backend data store directly via {{{getSparseTree()}}}, and work on the data structure directly. |
RowanChristmas - 10/03/05 -- A copy? or the actual CyData object? Getting a copy seems like it would be more or less useless as I would not be able to have my changes reflected anywhere. Also I am not sure what we gain by not having this class extend CyData/Definition directly. It seems like the logical way to go, especailly since both of those classes are already implemented by the same class.
EthanCerami - 10/4/05 - This is still very much open to debate, and I don't think anyone agrees 100% with my original proposal to have CyAttributes return CyData. However, if we were to adopt this approach, I agree it would have to return the actual CyData object, and not a copy or a clone. Otherwise, things would get really confusing. And, I definitely see the logic in having CyAttributes extend CyData / CyDefinition. However, I think there is also some logic in having CyAttributes embed CyData too.
My current thinking on this is that we rename CyData into something more meaningful, and more clearly tied to its role as a data structure. For example, we might consider renaming it to something like SparseTree. If that were the case, then we could simple say that CyAttributes uses a SparseTree as a back-end data structure, and CyAttributes provides simplified access to that data structure. If you want to add data that is any more complicated, you can obtain the backend data store directly via getSparseTree(), and work on the data structure directly.