Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be discussed separately. I do that because in the other message, I describe a real problem which needs a solution, and this message is about thinking about a solution in the archetype-framework, which will takes for years to come (if it will come, maybe I am wrong in my proposal).
---------------------
When talking about specializing. Specializing an archetype is nothing more then copying an archetype and add/change some constraints in them.

How different is that in programming languages, where the parent-classes are read to understand the child class. There is no need to process all the sourcecode of the child-classes to adapt the changes in a parent class. This is regarded as a big advantage for Object Oriented Programming. Easier to maintain code (and one definitely need a test framework).

Imagine that dreaded generic labtest archetype in the other message, I wrote today. How convenient would maintainability become if specializations where really and life-inherited from parent archetypes?

Would we need a big part of the LOINC-database of specialized labtest archetypes then, or would we just need to change the identifier and add the appropriate terminology binding?

Maybe we could, in case of lab-test, just created the child archetypes only in memory and on the fly, needing only a few keywords to describe the changes. We could take a look at hibernate for Java (or many other ORM-frameworks). They do not deliver the classes needed for handling specific databases, they offer a framework to create/generate those classes.

One could argue that specializations are not always inherited like classes in programming languages. That is true. What I suggest here maybe limited to the cases where it is real inheritance.

Best regards
Bert Verhees

_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to