Generally, you can do things in specifications that can't be reproduced in actual implementations. Since there is one specification, but many implementations, the list of things that the specification contains that aren't easy to implement varies widely between implementations. The things that are hard to implement are sometimes also very useful for expressing meaning and purpose. So a good specification balances between using things that are useful without using things that are too hard to use.
With regard to generics, my normal implementation contexts do not support generics (XML/XSD, old versions of various languages), but I still find them useful in the specifications and would prefer the specification expressed itself cleanly Grahame On Fri, Mar 23, 2012 at 11:51 AM, Peter Gummer <peter.gummer at oceaninformatics.com> wrote: > David Moner wrote: > >> I was exaclty thinking about this while seeing this proposal for the >> ITEM_STRUCTURE change to a VALUE_CLUSTER: >> >> http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.1AddVALUECLUSTER%2CRemoveITEMSTRUCTUREtypes >> >> It is an example of multiple inheritance not supported by Java and some >> other languages. > > > Multiple inheritance is easily implemented in Java and C# ... via interfaces. > > The problem is that you often need to duplicate code. For example, in that > diagram, VALUE_CLUSTER inherits from both ELEMENT and CLUSTER. In C# you > can't do that, so you would probably declare ValueCluster as implementing two > interfaces, IElement and ICluster; then you would copy the implementations of > Element and Cluster into ValueCluster. Java would do something similar, > although the naming convention of the interfaces might be different. (In C#, > you might even decide to avoid some of the code duplication by using > extension methods. Or maybe not ... it might cause more trouble than it > solves.) > > Peter > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- ----- http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
