On 22/03/2012 13:56, David Moner wrote:
>
>
> 2012/3/22 Thomas Beale <thomas.beale at oceaninformatics.com
> <mailto:thomas.beale at oceaninformatics.com>>
>
> Instead, I think we should re-invigorate the Java Implementation
> Technology Spec, that Rong wrote originally some years ago, to
> provide Java implementation guidance for issues like this. All
> target implementation technologies have their issues; if we keep
> hacking the primary specfication model to suit all of them, we
> will no longer have any clear statement at all of what we really
> wanted in the first place, and it would in any case probably be a
> very weak model, once you accommodate no generics, no multiple
> inheritance, no typing, ....!
>
>
>
> 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. I agree with you that a programming language
> limitation cannot be imposed to a good model design, but it is also
> true that for example Java is not a minor language to forget of. There
> should be a balance between what it is perfectly modelled and what can
> be implemented by most.
*
*
yes - I accept that in this case, and would not offer this MI structure
as a final proposal - I just did it this way to record the initial idea.
The final model should probably be one of:
* a new sibling of ELEMENT and CLUSTER, called e.g. VALUE_CLUSTER
* maybe replace ELEMENT and CLUSTER by a new merged class? Although
clinical modellers have told me they want sometimes to force just an
ELEMENT, no more children in some places.
* therefore, maybe a modified CLUSTER (with added 'value' element),
and the existing ELEMENT class. That would mean ITEM now has a 'value'.
I quite like the last idea.... it seems to me to reflect the reality
that 'any cluster could one day require a summarised value on itself'.
Time to update the wiki page ;-)
Re multiple inheritance in general, although we have beautiful multiple
inheritance in Eiffel (the language we did all the original modelling
in, starting from GEHR, but a very minor language these days), we
deliberately avoided using it in the openEHR reference model; instead,
we limited ourselves to the kind of inheritance supported by Java and
C#, i.e. only single inheritance for type substitution. I don't think
this compromise has hurt the models.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/1d69819e/attachment-0001.html>
