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 On Thu, Mar 22, 2012 at 1:44 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > 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: List<Item> 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 > DvInterval<T: 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 > > > _______________________________________________ > 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/bb5ba64d/attachment.html>
