David,
This
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.2ModifyCLUSTERtohavelocalvalue
is what I would realistically propose, for the CLUSTER/ELEMENT part of
the model. I will also post a
Two further variants are now up, with the second
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.4MakeITEMthefocal%27datastructure%27class
containing the more radical changes.
Comments welcome.
On 23/03/2012 12:09, Heath Frankel wrote:
I know every developer can do it better than the next but any
developer can do it better than a tool.
How true. That statement should be on the wall of every UML tool
vendor's office!
- thomas
If any developer would do better than a tool, why would anybody write tools
in the first place?
On Mon, Mar 26, 2012 at 3:26 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 23/03/2012 12:09, Heath Frankel wrote:
I know every developer can do it better than the next but
Developers are expensive, tools are reusable :D
--
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: Mon, 26 Mar 2012 15:43:15 +0100
Subject: Re: Suggestion to
Ok, thanks for the clarification.
Heath
On 23/03/2012 10:28 PM, Seref Arikan serefarikan at kurumsalteknoloji.com
wrote:
Hi Heath,
Just to clarify: my original issue is not about auto generation of classes
from XSD, whether or not one choses to do that is irrelevant if the XSD
itself is not
David Moner wrote:
I was exaclty thinking about this while seeing this proposal for the
ITEM_STRUCTURE change to a VALUE_CLUSTER:
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
I think the topic has drifted slight from Seref's original issue, although
Java nor c# can not implement generics as well as Eiffel or as intended by
the spec author it is possible to get close enough to be usable. Similar
implementation decisions were necessary when specifying the XML schema and
Hi Heath,
Just to clarify: my original issue is not about auto generation of classes
from XSD, whether or not one choses to do that is irrelevant if the XSD
itself is not supporting generics. The problem is with the XSD (not having
support for generics) and it may or may not cascade to programming
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
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
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,
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
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
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
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.
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
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
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
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
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
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
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
24 matches
Mail list logo
