Suggestion to replace use of generics with inheritence in future RM versions
Hi Seref, Ruby implementation might be one of the proof for replace of generics. I had much struggled to implement generics and got the conclusion that we do not need it. I felt low latency between UK and Japan! However, inheritance could be harmful, because it has too tight restriction for changes. Interface would be better. Cheers, Shinji(50msec latency) 2012/3/21 Seref Arikan serefarikan at kurumsalteknoloji.com: Greetings, Looking at the UML page Tom has posted a few minutes ago made me remember something I had in mind for some time. With hope of avoiding any flame wars and attempts to discuss elegance of various approaches in OO approach, may I suggest that the specs use inheritence instead of generics in the future? This is purely based on the current state of some key technologies. At the moment XSD has no generics support and Java's generics (or parameterized types) support has a feature (read: problem) called type erasure. XSD is the basis for both system to system and tool to tool communication, and that will not change for a significant time. So XSD based marshalling/unmarshalling to code will be reality for a while. Java is.. well it is Java, and its handling of generics won't change for at least a few more years. Most uses of the generics seem to use upper bounds for type parameters, so those cases should not be too hard to replace with inheritance with the upper bound as the type of fields that use generics at the moment. For unbounded type parameters (which are rare) we could define some assumed types in the implementing systems and either use an abstract class or find another workaround. That'd be a nice OO practice. This is a note I wanted to write somewhere. It may cause issues in terms of existing code bases and data, it may not be worth the effort, but in a world where algorithmic stock trading can justify a $1.5 billion cable between London and Tokyo to improve latency by 60ms, I should have the luxury of leaving my mark about this design choice ( http://www.extremetech.com/extreme/122989-1-5-billion-the-cost-of-cutting-london-toyko-latency-by-60ms ) Kind regards Seref ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
UCUM
well... good question. So in other words: if there is a units field
specifically for 'formal' units, is it UCUM only or not? I would have
said it should be except for annoying problems like the one Heath
mentioned - UCUM uses '*' for exponent instead of '^' which almost
everyone else uses
We could use the same approach as an openEHR DV_PARSABLE, where the name
of the syntax is stored as well, but this is IMO inviting a different
kind of pain...
My answer would be: let's get UCUM doing everything we need (for the
formal units field I mean, not the informal one); if we can't, we need a
new UCUM.
- thomas
Hi Thomas,
'^' is a special character in HL7 V2.x messages - so by changing '*'
back to '^' you would break implementations of HL7 ORU messages. We already
see this in some lab messages - if you try to parse the units field you get
x10 instead of x10^9/L, because OBX-6 is a coded element (CE) data type.
UCUM also uses annotations which are a bit unsightly e.g. mmol/mol creat is
expressed as mmol/mol {creat}. I'm all in favour of a display component
for units of measure - in the end you are still getting coded data.
Cheers,
Michael Osborne
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/99c0d0db/attachment.html
Units, Quantities, etc
Hi All, I think the units database that we have as part of openEHR tooling allows for the addition of equivalent and language dependent expressions, as well as conversion where that is possible. How about we make that available somewhere to get this going. It does mean we are not beholden to others and can know when we have UCUM compatible expressions (convert if necessary). Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Thomas Beale Sent: Wednesday, 21 March 2012 11:15 PM To: openehr-technical at lists.openehr.org Subject: Re: Units, Quantities, etc On 21/03/2012 09:28, Grahame Grieve wrote: But the question around can you trust the data is, can you recognize properly when the units are ucum or not? For some reason I haven't put my finger on, you are linking the knowing of this with the boundary of the type. It's not clear to me why you're making that link. Grahame well... good question. So in other words: if there is a units field specifically for 'formal' units, is it UCUM only or not? I would have said it should be except for annoying problems like the one Heath mentioned - UCUM uses '*' for exponent instead of '^' which almost everyone else uses We could use the same approach as an openEHR DV_PARSABLE, where the name of the syntax is stored as well, but this is IMO inviting a different kind of pain... My answer would be: let's get UCUM doing everything we need (for the formal units field I mean, not the informal one); if we can't, we need a new UCUM. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr- technical_lists.openehr.org
UCUM
you would just escape the ^ in the HL7 message
Grahame
On Thu, Mar 22, 2012 at 6:35 AM, Michael Osborne mjosborne1 at gmail.com
wrote:
well... good question. So in other words: if there is a units field
specifically for 'formal' units, is it UCUM only or not? I would have
said it should be except for annoying problems like the one Heath
mentioned - UCUM uses '*' for exponent instead of '^' which almost
everyone else uses
We could use the same approach as an openEHR DV_PARSABLE, where the name
of the syntax is stored as well, but this is IMO inviting a different
kind of pain...
My answer would be: let's get UCUM doing everything we need (for the
formal units field I mean, not the informal one); if we can't, we need a
new UCUM.
- thomas
Hi Thomas,
? ?'^' is a special character in HL7 V2.x messages - so by changing '*' back
to '^' you would break implementations of HL7 ORU messages. We already
see this in some lab messages - if you try to parse the units field you get
x10 instead of x10^9/L, because OBX-6 is a coded element (CE) data type.
UCUM also uses annotations which are a bit unsightly e.g. mmol/mol creat is
expressed as mmol/mol {creat}. I'm all in favour of a display component
for units of measure - in the end you are still getting coded data.
Cheers,
Michael Osborne
___
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
Suggestion to replace use of generics with inheritence in future RM versions
Shinji KOBAYASHI wrote: Ruby implementation might be one of the proof for replace of generics. I had much struggled to implement generics and got the conclusion that we do not need it. Ruby doesn't have generics at all, right, Shinji? There's a comparison of generics and inheritance in an appendix of Bertrand Meyer's Object Oriented Software Construction, 2nd edition. (http://se.ethz.ch/~meyer/publications/acm/geninh.pdf seems to be the original paper that the appendix is based upon.) Generics can be simulated in a language with inheritance, but there is a cost: * Duplication of code. * Extra verbosity. I don't want to have either forced upon me. If I'm unfortunately forced to use a language that doesn't support generics, then I can always simulate it the generics with inheritance. But I certainly wouldn't want the specs to be obfuscated by hacks like that, thanks very much ;-) Peter
Suggestion to replace use of generics with inheritence in future RM versions
Hi Peter, 2012/3/22 Peter Gummer peter.gummer at oceaninformatics.com: Shinji KOBAYASHI wrote: Ruby implementation might be one of the proof for replace of generics. I had much struggled to implement generics and got the conclusion that we do not need it. Ruby doesn't have generics at all, right, Shinji? It is right. I felt generics is very convenient, when I used Java, such as IteratorDvText it = someRmArrayInstance.iterator() But I found it must be cut off by 'Occam's razor' in Ruby. it = some_rm_array.iterator This code looks curious for Java/Eiffel/C# user who are similar to generics, but it is enough for encapsulated object instance. I think this depends on language environment, but nested generics seems complicated codes for me. List Map Integer, String Generics is useful to declare what instance is, but it breaks encapsulation. As regards to Bartrand Meyer's paper, 'a good balance' is a good design. Cheers, Shinji There's a comparison of generics and inheritance in an appendix of Bertrand Meyer's Object Oriented Software Construction, 2nd edition. (http://se.ethz.ch/~meyer/publications/acm/geninh.pdf seems to be the original paper that the appendix is based upon.) Generics can be simulated in a language with inheritance, but there is a cost: * Duplication of code. * Extra verbosity. I don't want to have either forced upon me. If I'm unfortunately forced to use a language that doesn't support generics, then I can always simulate it the generics with inheritance. But I certainly wouldn't want the specs to be obfuscated by hacks like that, thanks very much ;-) Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Suggestion to replace use of generics with inheritence in future RM versions
Hi all, Since this discussion is about how to implement things defined on the openEHR specs, I may suggest this is a topic of implementation technology specification instead of a change request to the specs. I mean, this is one of many things we need to consider when we implement openEHR in a certain technology, and if we can write down all those alternatives for each technology, we could have another layer of specifications, the ITS for Java|Ruby|.Net. E.g. HL7 has ITS specs. Just my 2 cents. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Thu, 22 Mar 2012 10:47:37 +0900 Subject: Re: Suggestion to replace use of generics with inheritence in future RM versions From: skoba at moss.gr.jp To: openehr-technical at lists.openehr.org Hi Peter, 2012/3/22 Peter Gummer peter.gummer at oceaninformatics.com: Shinji KOBAYASHI wrote: Ruby implementation might be one of the proof for replace of generics. I had much struggled to implement generics and got the conclusion that we do not need it. Ruby doesn't have generics at all, right, Shinji? It is right. I felt generics is very convenient, when I used Java, such as IteratorDvText it = someRmArrayInstance.iterator() But I found it must be cut off by 'Occam's razor' in Ruby. it = some_rm_array.iterator This code looks curious for Java/Eiffel/C# user who are similar to generics, but it is enough for encapsulated object instance. I think this depends on language environment, but nested generics seems complicated codes for me. List Map Integer, String Generics is useful to declare what instance is, but it breaks encapsulation. As regards to Bartrand Meyer's paper, 'a good balance' is a good design. Cheers, Shinji There's a comparison of generics and inheritance in an appendix of Bertrand Meyer's Object Oriented Software Construction, 2nd edition. (http://se.ethz.ch/~meyer/publications/acm/geninh.pdf seems to be the original paper that the appendix is based upon.) Generics can be simulated in a language with inheritance, but there is a cost: * Duplication of code. * Extra verbosity. I don't want to have either forced upon me. If I'm unfortunately forced to use a language that doesn't support generics, then I can always simulate it the generics with inheritance. But I certainly wouldn't want the specs to be obfuscated by hacks like that, thanks very much ;-) Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120321/1d0f4dc0/attachment-0001.html
Suggestion to replace use of generics with inheritence in future RM versions
Shinji KOBAYASHI wrote: IteratorDvText it = someRmArrayInstance.iterator() But I found it must be cut off by 'Occam's razor' in Ruby. it = some_rm_array.iterator This code looks curious for Java/Eiffel/C# user who are similar to generics, but it is enough for encapsulated object instance. Ruby is a dynamic language, so I guess it would have no need for generics. If you provide a wrongly typed object to a collection in Ruby, I imagine (never having programmed in Ruby myself) that you would find out about the error when you run the program. Eiffel, C# and Java try to catch errors like that during compilation. Generics is useful for those languages: it tries to keep the extra safety of compile-type checking, while providing some of the flexibility that you get in dynamic languages like Ruby. In the case of Java, generics don't work very well, as Seref pointed out. The JVM forced the Java designers to adopt a policy of type erasure. And so, on the one hand, the compiler is less flexible than Eiffel and C#, rejecting a lot of uses of generics that would be permitted in those other languages; and on the other hand, the Java byte code that you finish up running in the JVM contains no info about the generic parameter type. I'm not clear why the existence of generics in the spec would be a problem for a dynamic language like Ruby. Peter
Suggestion to replace use of generics with inheritence in future RM versions
Hi Pablo, I do not want to have a discussion about how to implement specs. That was not my point. Let me try to be more direct: Generics causes problems during implementation of openEHR if Java or XML is involved. Java + XML has a huge user base. Even XML on its own has a huge user base. By making a minor change in OO design options, openEHR can eliminate these problems for everyone using Java and especially XML. This may help openEHR become a spec easier to implement. This is the point I was trying to make. On Thu, Mar 22, 2012 at 2:06 AM, pablo pazos pazospablo at hotmail.com wrote: Hi all, Since this discussion is about how to implement things defined on the openEHR specs, I may suggest this is a topic of implementation technology specification instead of a change request to the specs. I mean, this is one of many things we need to consider when we implement openEHR in a certain technology, and if we can write down all those alternatives for each technology, we could have another layer of specifications, the ITS for Java|Ruby|.Net. E.g. HL7 has ITS specs. Just my 2 cents. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/?pablopazosgutierrezhttp://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.?blogspot.com/http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos Date: Thu, 22 Mar 2012 10:47:37 +0900 Subject: Re: Suggestion to replace use of generics with inheritence in future RM versions From: skoba at moss.gr.jp To: openehr-technical at lists.?openehr.orgopenehr-technical at lists.openehr.org Hi Peter, 2012/3/22 Peter Gummer peter.gummer@?oceaninformatics.competer.gummer at oceaninformatics.com : Shinji KOBAYASHI wrote: Ruby implementation might be one of the proof for replace of generics. I had much struggled to implement generics and got the conclusion that we do not need it. Ruby doesn't have generics at all, right, Shinji? It is right. I felt generics is very convenient, when I used Java, such as IteratorDvText it = someRmArrayInstance.iterator() But I found it must be cut off by 'Occam's razor' in Ruby. it = some_rm_array.iterator This code looks curious for Java/Eiffel/C# user who are similar to generics, but it is enough for encapsulated object instance. I think this depends on language environment, but nested generics seems complicated codes for me. List Map Integer, String Generics is useful to declare what instance is, but it breaks encapsulation. As regards to Bartrand Meyer's paper, 'a good balance' is a good design. Cheers, Shinji There's a comparison of generics and inheritance in an appendix of Bertrand Meyer's Object Oriented Software Construction, 2nd edition. ( http://se.ethz.ch/~meyer/?publications/acm/geninh.pdfhttp://se.ethz.ch/%7Emeyer/publications/acm/geninh.pdfseems to be the original paper that the appendix is based upon.) Generics can be simulated in a language with inheritance, but there is a cost: * Duplication of code. * Extra verbosity. I don't want to have either forced upon me. If I'm unfortunately forced to use a language that doesn't support generics, then I can always simulate it the generics with inheritance. But I certainly wouldn't want the specs to be obfuscated by hacks like that, thanks very much ;-) Peter __?_ openEHR-technical mailing list openEHR-technical at lists.?openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __?_ openEHR-technical mailing list openEHR-technical at lists.?openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/d153b8aa/attachment.html
Mandatory description at Term_definition
Hi, At the Term_definition section of the ADL specifications (1.4 and 1.5), we can read that Each term is defined using a structure of name/value pairs, and must at least include the names ?text? and ?description?, which are akin to the usual rubric, and full definition found in terminologies like SNOMED-CT. Although being in essence true, we can find examples where de description part is not needed. For example, at the openEHR-EHR-OBSERVATION.lab_test-histopathology.v1, we can see: [at0074] = text = Aborted description = * The * is the default value inserted by the archetype editor. Shouldn't have more sense to make description a not mandatory field? For very simple data items probably it will not be needed. This also applies to the constraint_definition that follows the same structure. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/f9dbff24/attachment.html
Archetype authoring attribution
Hello, Back again with the licensing topic of archetypes, with a real use case. We have been asked to help in creating a set of 13606 archetypes for breast and prostate cancer. Although they will probably incorporate some new requirements, the main source will be some of the openEHR archetypes available at the CKM. Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which is the state of that discussion), the doubts are the following: - Converting the archetype to a new reference model is considered as a derivation? Or the openEHR archetype is considered just as a reference material as could be any textbook or paper? - The author of the new archetype has to be the one of the openEHR archetype (Ian McNicoll btw) or the person who in fact creates the new RM-based archetype? The underlying question here that should be clarified is to define which is the extension of the concept derived work. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/1d3b44b5/attachment.html
Archetype authoring attribution
David, openEHR: Creative Commons license CC-BY-SA 2.0, applying to all openEHR.org achetypes hosted at the openEHR Clinical Knowledge Manager (CKM). http://creativecommons.org/licenses/by-sa/2.0/ My simplistic understanding. A derived work has to be derived. So when you use the information and transpose it as constraints on an other RM, then I consider this new archetype as derived from that new RM it is transposed to. So when this approach is followed then the Attribution is to the group that provided the clinical content. But there is no attribution to the openEHR RM specification. When you translate the text in the openEHR archetype to Dutch it is derived but still derived from the original openEHR RM. In this case attribution must be stated to openEHR RM and the clinical group. Is this an answer? Gerard Freriks +31 620347088 gfrer at luna.nl On 22 mrt. 2012, at 13:03, David Moner wrote: Hello, Back again with the licensing topic of archetypes, with a real use case. We have been asked to help in creating a set of 13606 archetypes for breast and prostate cancer. Although they will probably incorporate some new requirements, the main source will be some of the openEHR archetypes available at the CKM. Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which is the state of that discussion), the doubts are the following: - Converting the archetype to a new reference model is considered as a derivation? Or the openEHR archetype is considered just as a reference material as could be any textbook or paper? - The author of the new archetype has to be the one of the openEHR archetype (Ian McNicoll btw) or the person who in fact creates the new RM-based archetype? The underlying question here that should be clarified is to define which is the extension of the concept derived work. David -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/eca31ee3/attachment-0001.html
Suggestion to replace use of generics with inheritence in future RM versions
On 22/03/2012 09:34, Seref Arikan wrote: Hi Pablo, I do not want to have a discussion about how to implement specs. That was not my point. Let me try to be more direct: Generics causes problems during implementation of openEHR if Java or XML is involved. Java + XML has a huge user base. Even XML on its own has a huge user base. By making a minor change in OO design options, openEHR can eliminate these problems for everyone using Java and especially XML. This may help openEHR become a spec easier to implement. This is the point I was trying to make. * * I am not sure that this is an argument for removing generics though. Lots of people 'use' XML, but they don't model in it - it is unusable for object-oriented modelling. I think most XML schemas are built as a particular data view of an object model, for a particular kind of communication channel. There are obviously going to be many non-XML communication channels in the future, as there already are inside major orgs like Google and Amazon, where binary messaging is being used. And it's easy enough to create an XSD from an object model. It's annoying that XML is too dumb to do things like generics natively, but not the end of the world. As for Java, I don't think we should remove the numerous uses of generics in the model due to Java's poor implementation of them. For example, nearly every LOCATABLE descendant in openEHR (RECORD_COMPONENT descendants in 13606) have some generic declaration, e.g. Cluster.members: ListItem etc. I don't think creating hardwired classes like ListItem, ListSection, ListEntry, ListParticipation etc is a reasonable option for a clear model. There are a few instances in openEHR of non-container generics, like DvIntervalT: DvOrdered and so on. I don't really think we should compromise the model here either - the specification says exactly the intended semantics, in a clear and comprehensible way. 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, ! - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/8e9465da/attachment.html
Suggestion to replace use of generics with inheritence in future RM versions
2012/3/22 Thomas Beale 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. -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/35ce4106/attachment.html
Suggestion to replace use of generics with inheritence in future RM versions
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
Suggestion to replace use of generics with inheritence in future RM versions
I have to say, software development would be absolutely dire from my point of view without one particular generic type: HashT, K. That really would destroy nearly every class I have ever written! - thomas On 22/03/2012 01:47, Shinji KOBAYASHI wrote: Hi Peter, 2012/3/22 Peter Gummerpeter.gummer at oceaninformatics.com: Shinji KOBAYASHI wrote: Ruby implementation might be one of the proof for replace of generics. I had much struggled to implement generics and got the conclusion that we do not need it. Ruby doesn't have generics at all, right, Shinji? It is right. I felt generics is very convenient, when I used Java, such as IteratorDvText it = someRmArrayInstance.iterator() But I found it must be cut off by 'Occam's razor' in Ruby. it = some_rm_array.iterator This code looks curious for Java/Eiffel/C# user who are similar to generics, but it is enough for encapsulated object instance. I think this depends on language environment, but nested generics seems complicated codes for me. ListMapInteger, String Generics is useful to declare what instance is, but it breaks encapsulation. As regards to Bartrand Meyer's paper, 'a good balance' is a good design. Cheers, Shinji There's a comparison of generics and inheritance in an appendix of Bertrand Meyer's Object Oriented Software Construction, 2nd edition. (http://se.ethz.ch/~meyer/publications/acm/geninh.pdf seems to be the original paper that the appendix is based upon.) Generics can be simulated in a language with inheritance, but there is a cost: * Duplication of code. * Extra verbosity. I don't want to have either forced upon me. If I'm unfortunately forced to use a language that doesn't support generics, then I can always simulate it the generics with inheritance. But I certainly wouldn't want the specs to be obfuscated by hacks like that, thanks very much ;-) Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Society http://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/282651c9/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/282651c9/attachment.jpg
Suggestion to replace use of generics with inheritence in future RM versions
On 22/03/2012 14:04, Seref Arikan wrote: I have workarounds for the generics problems in Java, and I would be more than hapy to contribute them to any doc. I did not know about Rong's document. I think I have made my point, whether or not it is a good one is a different issue, but I don't want it to be read as an open ended suggestion for throwing away good OO features. Best regards Seref* * it is actually on the normal spec page http://www.openehr.org/releases/1.0.2/roadmap.html, see bottom of 'stable' specs group (direct link to PDF http://www.openehr.org/releases/1.0.2/its/Java/openEHR-JavaITS.pdf). - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/48695395/attachment.html
Are you doing an academic project using openEHR?
On 19/03/2012 03:01, pablo pazos wrote: Hi Thomas, we are here: http://www.openehr.org/shared-resources/usage/nonprofit.html * * I knew that...! -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/fce15c40/attachment.html
Suggestion to replace use of generics with inheritence in future RM versions
I should have been more specific. Generics in collections is a managable issue :) and yes, I would not like to go back to non-generic collections either.. On Thu, Mar 22, 2012 at 2:26 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: I have to say, software development would be absolutely dire from my point of view without one particular generic type: HashT, K. That really would destroy nearly every class I have ever written! - thomas On 22/03/2012 01:47, Shinji KOBAYASHI wrote: Hi Peter, 2012/3/22 Peter Gummer peter.gummer@?oceaninformatics.com peter.gummer at oceaninformatics.com: Shinji KOBAYASHI wrote: Ruby implementation might be one of the proof for replace of generics. I had much struggled to implement generics and got the conclusion that we do not need it. Ruby doesn't have generics at all, right, Shinji? It is right. I felt generics is very convenient, when I used Java, such as IteratorDvText it = someRmArrayInstance.iterator() But I found it must be cut off by 'Occam's razor' in Ruby. it = some_rm_array.iterator This code looks curious for Java/Eiffel/C# user who are similar to generics, but it is enough for encapsulated object instance. I think this depends on language environment, but nested generics seems complicated codes for me. List Map Integer, String Generics is useful to declare what instance is, but it breaks encapsulation. As regards to Bartrand Meyer's paper, 'a good balance' is a good design. Cheers, Shinji There's a comparison of generics and inheritance in an appendix of Bertrand Meyer's Object Oriented Software Construction, 2nd edition. (http://se.ethz.ch/~meyer/?publications/acm/geninh.pdf http://se.ethz.ch/%7Emeyer/publications/acm/geninh.pdf seems to be the original paper that the appendix is based upon.) Generics can be simulated in a language with inheritance, but there is a cost: * Duplication of code. * Extra verbosity. I don't want to have either forced upon me. If I'm unfortunately forced to use a language that doesn't support generics, then I can always simulate it the generics with inheritance. But I certainly wouldn't want the specs to be obfuscated by hacks like that, thanks very much ;-) Peter __?_ openEHR-technical mailing list openEHR-technical at lists.?openehr.org openEHR-technical at lists.openehr.orghttp://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __?_ openEHR-technical mailing listopenEHR-technical at lists.?openehr.org openEHR-technical at lists.openehr.orghttp://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- [image: Ocean Informatics] *Thomas Beale Chief Technology Officer, Ocean Informaticshttp://www.oceaninformatics.com/ * Chair Architectural Review Board, *open*EHR Foundationhttp://www.openehr.org/ Honorary Research Fellow, University College Londonhttp://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Societyhttp://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/45f6c2bb/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/45f6c2bb/attachment-0001.jpg
Suggestion to replace use of generics with inheritence in future RM versions
Hi Seref, I understood your point. The fact is that this is a change request to the specs, and IMO things like these could be defined on annexes to the specs, in this case something like if you are implementing things in Java you'll have these problems with generics, so you can do things easier implementing the model this way The problem I see is the specs shouldn't be changed for a technology issue, or maybe yes, if we consider the 4 or 5 big technologies out there, but not only one. My point is: I agree with you no making something to simplify the implementation, I don't agree to do it by changing the model. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Thu, 22 Mar 2012 09:34:16 + Subject: Re: Suggestion to replace use of generics with inheritence in future RM versions From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Hi Pablo, I do not want to have a discussion about how to implement specs. That was not my point. Let me try to be more direct: Generics causes problems during implementation of openEHR if Java or XML is involved. Java + XML has a huge user base. Even XML on its own has a huge user base. By making a minor change in OO design options, openEHR can eliminate these problems for everyone using Java and especially XML. This may help openEHR become a spec easier to implement. This is the point I was trying to make. On Thu, Mar 22, 2012 at 2:06 AM, pablo pazos pazospablo at hotmail.com wrote: Hi all, Since this discussion is about how to implement things defined on the openEHR specs, I may suggest this is a topic of implementation technology specification instead of a change request to the specs. I mean, this is one of many things we need to consider when we implement openEHR in a certain technology, and if we can write down all those alternatives for each technology, we could have another layer of specifications, the ITS for Java|Ruby|.Net. E.g. HL7 has ITS specs. Just my 2 cents. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/?pablopazosgutierrez Blog: http://informatica-medica.?blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/7e7dcd3b/attachment.html
