# Java v.s. Eiffel + What should the setters do as mandatory checks... **Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154) **Created:** 2007-01-12 14:47 UTC **Views:** 3 **Replies:** 18 **URL:** https://discourse.openehr.org/t/java-v-s-eiffel-what-should-the-setters-do-as-mandatory-checks/14604 --- ## Post #1 by @erik.sundvall Hi\! > well whatever you do, don't try it \[Eiffel\] now, otherwise you will go mad when you go > back to do something in Java ;\-\) I agree that Java as in \_the Java language\_ is not always ideal and not the most productive environment\. I'm not a seasoned expert but some experience with e\.g\. Smalltalk and Python has shown interesting features \(closures, mixins etc\.\) that Java does not have \(yet\) but that are available in e\.g\. Ruby, Groovy etc\. I still think having an openEHR reference implementation in Java is very important, probably the strategically most important reference implementation for openEHR\. Java as in the \_JVM\_ \(that runs almost anywhere\) and the ecosystem around Java with a multitude of libraries and products is very attractive\. Now if we get a truly extendable and usable java\-ref\-impl library it can be used smoothly with\.\.\. \.\.\.several languages, e\.g\.: JRuby, http://jruby.codehaus.org/ Groovy, http://groovy.codehaus.org/ Jython, http://www.jython.org/ Scala, http://scala.epfl.ch/ \.\.\.and in several environments/setups, some random examples are: http://www.terracotta.org/ http://code.google.com/webtoolkit/ http://www.springframework.org/ So let's go on discussing a bit about the future and what will be good in order to possibly use the same java\-ref\-impl in many settings and languages\. When we discussed http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html I specifically mentioned what they said about using setters instead of assertions for preconditions because I wanted a discussion on this\. Rong seems to go for what the document says and Thomas had a somewhat different approach coming from the Eiffel culture\. Below I'll try to explain better what I think should be done and not in order to have a solution that fits into the Java culture and that is at the same "configurable" in some sense\. I tend to agree with Rong that in Java, the usual way to check preconditions is to throw an exception on wrong usage\. The environment will show the caller what went wrong and where, just as I guess that DbC preconditions in Eiffel work\. Thomas said that preconditions often are switched on in runtime \(with a 5% additional processing cost\)\. So doing \_some\_ important mandatory checks in setters would probably be a normal and good java\-way of doing things\. Even though many are unnecessary when reading from database it could be an OK default behaviour for the reference API\. If the properties are protected instead of private, then the setters and their checks \(all or selected ones\) can be overridden anyway if they are detected as significant bottlenecks in performance profiling of some runtime system\. So yes, checks in setters can be a good way to do preconditions in java, and having protected properties instead of private will cover the possible "configuration"\-need for this\. So, what should the setters avoid as mandatory checking? I'd say checking things in a way that forces the user to populate the objects properties in a certain order is what should not be mandatory\. The reason is that many usages demand an arbitrary order of property population, some persistence and GUI solutions are examples\. In these cases you might want to have the object in an illegal or inconsistent state for a while during build up and then call validation when you are finished\. I believe Bert reported such a problem in "AuthoredResource\.java" in a posting on Jan 8\. If a certain order is demanded, then you might need to use special builder classes \(like the RM\-builder\) or you'll end up constructing a parallel mutable hierarchy of custom coded objects that you then pass to some building process \(we have seen this happen here when using the current code\)\. If you instead have a choice to use mutable classes that allow arbitrary population order, then coders can avoid a lot of work\. We have to consider how a library affects the users of the library, solutions that lead to simple and elegant code within the library but to unnecessarily complicated client code used to call the library should be avoided\. Invariants could \(depending on how they are written\) cause problems with arbitrary incremental object population\. How does this look in openEHR \(the invariants in the spec\)? Do they allow arbitrary order of property population or not? If we use assertions for invariants, they could be turned om and off depending on what you want\. The same goes for postconditions\. This would cover the "configuration" need for this part, but what do we do if we want post\-conditions on but not invariants? Any suggestions? An extra if\-statement in the assertions checking a boolean configuration variable? \(Sounds a bit too much like a "home\-made\-hack" maybe?\) Now, using assertions does not prevent us to also have comments containing JML DbC rules if someone feels like adding and using that\. I do suspect that using the JML kind of DbC is not very common in the Java culture\. It sounds like Thomas has managed to get DbC used by \.net\-people at Ocean, but I'd guess that is more of an exception than a rule regarding environments that will use the java\-ref\-impl\. Assertions and \(limited\) setter checks is more java\-style\. A side note to Thomas who I believe considers setters and getters are a clumsy detour in order to change properties: Many of the alternative JVM languages mentioned above and some scripting solutions \(velocity etc\.\) hide the "set" and "get" parts of java\-bean\-style objects and let's your code treat the library as if the the properties are directly accessed, but under the surface setters can do precondition checks etc\. By the way I saw that JRuby is "Distributed under a tri\-license \(CPL/GPL/LGPL\)" note that CPL is the Eclipse thing\. This could be interesting to study regarding the previously mentioned Eclipse OHF\. I guess a quad licence would be quite possible too, but let's have the IBM lawyers look at that later if necessary\. Best regards, Erik Sundvall http://www.imt.liu.se/~erisu/ P\.s\. related link: http://www.artima.com/weblogs/viewpost.jsp?thread=173229 --- ## Post #2 by @system > So, what should the setters avoid as mandatory checking? I'd say > checking things in a way that forces the user to populate the objects > properties in a certain order is what should not be mandatory\. The > reason is that many usages demand an arbitrary order of property > population, some persistence and GUI solutions are examples\. In these > cases you might want to have the object in an illegal or inconsistent > state for a while during build up and then call validation when you > are finished\. I believe Bert reported such a problem in > "AuthoredResource\.java" in a posting on Jan 8\. >   That is correct, that is exact what I reported Bert --- ## Post #3 by @system Bert Verhees schreef: >> So, what should the setters avoid as mandatory checking? I'd say >> checking things in a way that forces the user to populate the objects >> properties in a certain order is what should not be mandatory\. The >> reason is that many usages demand an arbitrary order of property >> population, some persistence and GUI solutions are examples\. In these >> cases you might want to have the object in an illegal or inconsistent >> state for a while during build up and then call validation when you >> are finished\. I believe Bert reported such a problem in >> "AuthoredResource\.java" in a posting on Jan 8\. >>   > > That is correct, that is exact what I reported >   That is to say, it was in another class, but the problem is like you described\. There more problems witrh getter/setters and hibernate, I must point to\. Don't put logic in the seters which can fire an exception, how should hibernate handle this? As is the case, it stops, because of a uncaught exception, which can lead to unpredictable results in a application\. You can say, in OpenEhr, where there is not much relational use of a database in normal EHR use, data in the database will not change, because no other objects touch them, so data coming from the persistence always are valid\. Because they were checked just before writing them\. And if setters are only used for persistence\-layers \(make them protected instead of public\), there is no need to do DbC in setters Bert --- ## Post #4 by @thomas.beale Bert Verhees wrote: --- ## Post #5 by @thomas.beale Bert Verhees wrote: > ``` > You can say, in OpenEhr, where there is not much relational use of a > database in normal EHR use, data in the database will not change, > because no other objects touch them, so data coming from the > persistence always are valid. Because they were checked just before > writing them. > > > ``` I think everyone using openEHR persistently is using a relational database to do it. - thomas --- ## Post #6 by @system Thomas Beale schreef: > Bert Verhees wrote: >> >> You can say, in OpenEhr, where there is not much relational use of a >> database in normal EHR use, data in the database will not change, >> because no other objects touch them, so data coming from the >> persistence always are valid\. Because they were checked just before >> writing them\. >> > > I think everyone using openEHR persistently is using a relational > database to do it\.e best > \- thomas Yes that is true, that is the common tool, also familiar\. Not necessarily the best, but it can do very good\. But that is not what openehr is designed to, because most of the classes do not interact on a relational way \(like Codd had in mind\), they could as well be blobbed, it would functionally make no difference at all for normal EHR use, but it would in performance\. The only thing to solve is that fast datamining will be impossible to do on blob's\. So I started thinking towards hybrid solutions: I was thinking: \- \- for EHR\-use, to use blobs for high performance store and retrieval \- \- and parts of the classes \(have not thought about yet it which\) also store relational to make datamining possible, they can then be written with low priority, eventually retrieved from the blobbed data, and created once a day\. The blobs eventually before can be translated to XML \(got the idea from Thomas, a good listener \(like me\) only needs half a word, we say in Holland\) and then other techniques are possible to retrieve datastructures\. But that are only thoughts\. Fact is that most of OpenEhr is not a relational class model, \(if that is good English?\), this fact gives us a lot of freedom to choose implementation\-forms\. For my choice at this moment, I work purely relational, and see where I will get at, after that I will start tuning by partly blobbing or "XML\-blobbing", and see what will be necessary to do, or maybe use multiple database\-engines of different kind \(which is only a matter of configuration\-files\)\. Good to have so many opportunities\. Maybe, we can discuss things with other people having experience with Openehr\-persistence\. I see that sometimes, the depht of data storage in relational storage goes to far\. We'll see about that, it is almost ready, it was quite a job, lots of difficulties to overcome, really, but I think it was worth it\. Some difficulties I am still in, the tuning of the MySQL InnoDB parameters, for example, because of the data bombardments going to the database, f\.e\. when storing a Composition, and also the way back\.\.\.\.\. Bert --- ## Post #7 by @thomas.beale Bert Verhees wrote: > ``` > > Yes that is true, that is the common tool, also familiar. Not > necessarily the best, but it can do very good. > But that is not what openehr is designed to, because most of the classes > do not interact on a relational way (like Codd had in mind), they could > as well be blobbed, it would functionally make no difference at all for > normal EHR use, but it would in performance. > > ``` that's true, but there is nothing special about openEHR. No object model fits a relational database well. Hence the need for all the object mapping generally. > ``` > The only thing to solve is that fast datamining will be impossible to do > on blob's. > > So I started thinking towards hybrid solutions: > I was thinking: > - - for EHR-use, to use blobs for high performance store and > retrieval > - - and parts of the classes (have not thought about yet it which) > also store relational to make datamining possible, they can then be > written with low priority, eventually retrieved from the blobbed data, > and created once a day. > > ``` this kind of thing is pretty common, and has been done for years, e.g. in Health.one (Belgian HIS), based on GEHR, the precursor to openEHR. There will be many variations on the theme, and experience will tell the best for each situation, but I doubt if one is best for all situations. - thomas --- ## Post #8 by @system Thomas Beale schreef: > Bert Verhees wrote: >> >> Yes that is true, that is the common tool, also familiar\. Not >> necessarily the best, but it can do very good\. >> But that is not what openehr is designed to, because most of the classes >> do not interact on a relational way \(like Codd had in mind\), they could >> as well be blobbed, it would functionally make no difference at all for >> normal EHR use, but it would in performance\. >>   > > that's true, but there is nothing special about openEHR\. No object > model fits a relational database well\. Hence the need for all the > object mapping generally\. It depends, the Codd idea was also about sharing of data, better/easier for maintaining\. One can imagine object\-models which have typical relational characteristics\. But OpenEhr does not have, that is what counts\. >> The only thing to solve is that fast datamining will be impossible to do >> on blob's\. >> >> So I started thinking towards hybrid solutions: >> I was thinking: >> \- \- for EHR\-use, to use blobs for high performance store and >> retrieval >> \- \- and parts of the classes \(have not thought about yet it which\) >> also store relational to make datamining possible, they can then be >> written with low priority, eventually retrieved from the blobbed data, >> and created once a day\. >>   > > this kind of thing is pretty common, and has been done for years, e\.g\. > in Health\.one \(Belgian HIS\), Health One doess not use databases for their regular store, \(as if I remember well\), they use a proprietary file format base on memory dumps of object\-constructs \(every EHR, one file\), and besides that, they indeed use a regular database\-engine to do other things, like datamining, publishing data to webservers, reports, etc\. In my humble opinion it is a handicap to must work with a own data/memorydump format\. Every connection to modern generally used technique must be tricked, and causes extra code, proprietary and not reusable code > based on GEHR, the precursor to openEHR\. There will be many variations > on the theme, and experience will tell the best for each situation, > but I doubt if one is best for all situations\. true, it is a matter of taste, so to say\. regards Bert --- ## Post #9 by @erik.sundvall Hi\! Another candidate if someone would like DbC: http://www.contract4j.org/ Based on, guess what, aspect oriented programming and Java annotations ;\-\) \(You can configure/enable/disable the DbC stuff at runtime if you want\. It works for java 5 and also 6 I believe\.\) The example\.\.\. http://www.contract4j.org/contract4j/example \.\.\.points out that assertion based DbC code can make objects a bit messy\. Do you think this would be a problem or not for the ref\-impl\-java code? > PS: \(get my hobby in attention, already moved to the PS\-part of an email ;\-\) > That is why we need to work on a base\-code for conformance and reference > purposes\. > \(how can we do that, I have not seen an idea now, or I missed it, > please, then forgive me\) Oh, I think a couple of ideas have been mentioned\. An incomplete summary list : \- Simple mutable POJO/bean\-style objects with only simple default validation on setters \(so that arbitrary property population is allowed\)\. \- The properties in these POJOs should be protected not private\. \- The POJOs described above could have a validation\(\) method that checks the object \(and possibly its children when called\. \- Separate packages with classes that extend the POJOs but that are immutable and check everything at object creation\. \(Setters will throw exceptions\) \- Helper classes that can create an immutable object based on POJO and the other way around\. \- Rong also suggested "wrappers" as a possible solution \(Rong feel free to clarify this, wrappers can mean so many different things to different people\. Would these wrappers look like simple POJOs or would they require some kind of factory to be created? What would be wrapped within what? Would it be a simpler solution than having immutable objects that inherit from POJO\-style objects?\) Best regards, Erik Sundvall http://www.imt.liu.se/~erisu/ --- ## Post #10 by @system > Hi\! > > Another candidate if someone would like DbC: > http://www.contract4j.org/ > > Based on, guess what, aspect oriented programming and Java annotations ;\-\) > \(You can configure/enable/disable the DbC stuff at runtime if you > want\. It works for java 5 and also 6 I believe\.\) > > The example\.\.\. > http://www.contract4j.org/contract4j/example > \.\.\.points out that assertion based DbC code can make objects a bit > messy\. Do you think this would be a problem or not for the > ref\-impl\-java code? > > > PS: \(get my hobby in attention, already moved to the PS\-part of an email ;\-\) > > That is why we need to work on a base\-code for conformance and reference > > purposes\. > > \(how can we do that, I have not seen an idea now, or I missed it, > > please, then forgive me\) > > Oh, I think a couple of ideas have been mentioned\. An incomplete summary list : > \- Simple mutable POJO/bean\-style objects with only simple default > validation on setters \(so that arbitrary property population is > allowed\)\. > \- The properties in these POJOs should be protected not private\. I would agree with that, for me it is the same as interfaces, almost empty getter/setters, no semantics of the refenrence model in it, that would come in derived layers > \- The POJOs described above could have a validation\(\) method that > checks the object \(and possibly its children when called\. I would not favour that, because, IMHO the getter/setters are only used for storage\-purpose, and they should not validate\. How to handle exceptions, would be aproblem, and thereby, everything that coems through it, is already checked at higher derived level, or at contructor \(as it is now\)\. Aand also validation methods contain semaantic information, which should not be there at that level\. > \- Separate packages with classes that extend the POJOs but that are > immutable and check everything at object creation\. \(Setters will throw > exceptions\) Exactly > \- Helper classes that can create an immutable object based on POJO and > the other way around\. I would like to see some examples, also examples on Rongs\-wrappers\. > \- Rong also suggested "wrappers" as a possible solution \(Rong feel > free to clarify this, wrappers can mean so many different things to > different people\. Would these wrappers look like simple POJOs or would > they require some kind of factory to be created? What would be wrapped > within what? Would it be a simpler solution than having immutable > objects that inherit from POJO\-style objects?\) We'll see, when do we start\.? I must have missed this wrapper\-discussion, I do not read everything, which in a quick scan does not seem to fit in my thinking, sometimes I mis something\. I would like to get this started as quick as possible, and I can offer some help, as soon as we have a steady plan\. regards Bert --- ## Post #11 by @erik.sundvall Hi\! Just some clarifications\. > > \- The POJOs described above could have a validation\(\) method that > > checks the object \(and possibly its children when called\. Correction: validate\(\) would be better than validation\(\) > I would not favour that, because, IMHO the getter/setters are only used for > storage\-purpose, and they should not validate\. How to handle exceptions, > would be aproblem, and thereby, everything that coems through it, is already > checked at higher derived level, or at contructor \(as it is now\)\. > And also validation methods contain semaantic information, which should > not be there at that level\. Sorry if I was not explaining this good enough\. I only meant that the validation method could be provided as a method that validates the entire object \_if\_ the application designer chooses to call it, for example when they consider their calling code to be finished with object creation after finishing parsing of an incoming XML\-message\. Validate\(\) should not be called automatically by setters in the base class, but some overriding implementation might want to call validate\(\) in their setters or constructors though and those coders would then not need to write their own validation code\. \(Related repetition: Some simple argument checking in setters might be OK if the community feels that this would be good\. That is common Java culture practice and can catch a couple of bugs in a familiar manner\.\) A word of warning though: having a validate\(\) method might be completely unneccesary if we have other ways of validating an object or object structure\. Some examples: \- DbC activated \(that would check RM conformance\) \- An external RM\-validator class that traverses and validates the object or object structure\. \- An external RM\-validator class that traverses the object or object structure and at the same time is Archetype aware and checks for constraints based on both the RM and the archetypes used within the structure\. I guess that the last two in the list are similar to what is done in the current code of the RM builder and when creating RM instances from an archetype object\. The difference is that clients can populate real RM objects and object structures with data instad of populating maps with attribute names and objects\. I believe that one then in many situations \(not all scenarios\) will get better support from an IDE and the compiler to catch potential bugs before runtime\. > > \- Helper classes that can create an immutable object based on POJO and > > the other way around\. > I would like to see some examples, also examples on Rongs\-wrappers\. I agree that examples and some experiments would be good before starting any major redesign\. > I would like to get this started as quick as possible, and I can offer some help, > as soon as we have a steady plan\. Rong is working on a roadmap for the java\-ref\-impl\. http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm \(I found in SVN now with the help of Mattias, links from the website are missing or hard to find\. There are also other interesting documents in: http://svn.openehr.org/ref_impl_java/TRUNK/docs/) I believe this discussion can give input to the roadmap\. Rong is also stabilizing and fixing the current java\-ref\-impl version and I think it is good that improving the current version has priority over discussions about the future\. Experiments with mutable objects etc\. should probably be done in a separate SVN branch if we want them version controlled by openEHR, and probably more people than Rong should be involved in contributing and committing code to that branch since Rong has other things to do in life too ;\-\) Best regards, Erik Sundvall http://www.imt.liu.se/~erisu/ --- ## Post #12 by @system > Rong is working on a roadmap for the java-ref-impl. > [http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm](http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm) > (I found in SVN now with the help of Mattias, links from the website > are missing or hard to find. There are also other interesting > documents in: [http://svn.openehr.org/ref_impl_java/TRUNK/docs/](http://svn.openehr.org/ref_impl_java/TRUNK/docs/)) Well, I plan to post the link to the list for discussion before I manage to include some comments from a small group of people who have reviewed this document. But thanks anyway. Here are things on the to-do for this doc so that you know what' coming - better categories ( e.g. Applications instead of Tools); status of each components and a overview diagram which includes all the components and how they fit into a full-blown system. Cheers, Rong --- ## Post #13 by @system Erik Sundvall schreef: > Hi\! > > Just some clarifications\. > >>> \- The POJOs described above could have a validation\(\) method that >>> checks the object \(and possibly its children when called\. >>>       > Correction: validate\(\) would be better than validation\(\) > >> I would not favour that, because, IMHO the getter/setters are only used for >> storage\-purpose, and they should not validate\. How to handle exceptions, >> would be aproblem, and thereby, everything that coems through it, is already >> checked at higher derived level, or at contructor \(as it is now\)\. >> And also validation methods contain semaantic information, which should >> not be there at that level\. >>     > Sorry if I was not explaining this good enough\. I only meant that the > validation method could be provided as a method that validates the > entire object \_if\_ the application designer chooses to call it, for > example when they consider their calling code to be finished with > object creation after finishing parsing of an incoming XML\-message\. > Validate\(\) should not be called automatically by setters in the base > class, but some overriding implementation might want to call > validate\(\) in their setters or constructors though and those coders > would then not need to write their own validation code\. >   I agree > \(Related repetition: Some simple argument checking in setters might be > OK if the community feels that this would be good\. That is common Java > culture practice and can catch a couple of bugs in a familiar manner\.\) >   I could not think about a purpose for this, as the base\-class setters are only used by persistence\-layers and only will be used by what has been written by the getters to the persistence\-store\. > A word of warning though: having a validate\(\) method might be > completely unneccesary if we have other ways of validating an object > or object structure\. Some examples: > \- DbC activated \(that would check RM conformance\) > \- An external RM\-validator class that traverses and validates the > object or object structure\. > \- An external RM\-validator class that traverses the object or object > structure and at the same time is Archetype aware and checks for > constraints based on both the RM and the archetypes used within the > structure\. >   I agree, but that is a higher level where setters can be used by application programmers\. This is another discussion > I guess that the last two in the list are similar to what is done in > the current code of the RM builder and when creating RM instances from > an archetype object\. The difference is that clients can populate real > RM objects and object structures with data instad of populating maps > with attribute names and objects\. I believe that one then in many > situations \(not all scenarios\) will get better support from an IDE and > the compiler to catch potential bugs before runtime\. >   It suddenly appeared for my nose\. I have to study that\. Today was such a big Java update, I am a bit confused by that, I must think how to handle this\. it is all trunk, that is true, I ask this question in a separate message >   >>> \- Helper classes that can create an immutable object based on POJO and >>> the other way around\. >>>       >> >> I would like to see some examples, also examples on Rongs\-wrappers\. >>     > I agree that examples and some experiments would be good before > starting any major redesign\. > >> I would like to get this started as quick as possible, and I can offer some help, >> as soon as we have a steady plan\. >>     > Rong is working on a roadmap for the java\-ref\-impl\. > http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm > \(I found in SVN now with the help of Mattias, links from the website > are missing or hard to find\. There are also other interesting > documents in: http://svn.openehr.org/ref_impl_java/TRUNK/docs/) >   I hate looking to TRUNK, it is a moving target, it does not help me\. My target is finishing an implementation\. I don't have time to follow new ideas on moving targets\. I can learn from that but not implement that\. > I believe this discussion can give input to the roadmap\. > > Rong is also stabilizing and fixing the current java\-ref\-impl version > and I think it is good that improving the current version has priority > over discussions about the future\. >   Which is current? > Experiments with mutable objects etc\. should probably be done in a > separate SVN branch if we want them version controlled by openEHR, and >   I don't know, we had a branch sandbox, it disappeared, we had a branch rm\-splitted, it disappeared\. I guess, some ideas are better done in forks, and maybe ported partly back, if the fork brought good ideas\. maybe fork is the same as branch in your way of speaking, but forks do not disappear suddenly\. They even can be maintained, if someone likes to do that\. > probably more people than Rong should be involved in contributing and > committing code to that branch since Rong has other things to do in > life too ;\-\) >   I agree, more people should have a chance to get involved\. It is good for Rong, but also for the project\. It never is good if a project depends too much on one person\. There must be an infrastructure to let others be involved\. Bert --- ## Post #14 by @thomas.beale Erik Sundvall wrote: > ``` > Sorry if I was not explaining this good enough. I only meant that the > validation method could be provided as a method that validates the > entire object _if_ the application designer chooses to call it, for > example when they consider their calling code to be finished with > object creation after finishing parsing of an incoming XML-message. > Validate() should not be called automatically by setters in the base > class, but some overriding implementation might want to call > validate() in their setters or constructors though and those coders > would then not need to write their own validation code. > > > ``` this problem is a well-known one in non-trivial software. The invariants that should be true after creation only relate to a minimal version of an object, created in any circumstance. The validate() - I usually use the method name is_valid: Boolean for this purpose - is about business level validity of the object, and can only be called at sensible points. You can see an example in the Eiffel version of the ARCHETYPE class: [http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/libraries/openehr/src/am/archetype/archetype.e?op=file&rev=0&sc=0](http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/libraries/openehr/src/am/archetype/archetype.e?op=file&rev=0&sc=0) Look at the is_valid method (about halfway down), and the invariants (at the bottom). Note that "is_valid" is not mentioned in the invariants. You can see that is_valid is called by the ADL_INTERFACE class in the parser: [http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/components/adl_parser/src/interface/adl_interface.e?op=file&rev=0&sc=0](http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/components/adl_parser/src/interface/adl_interface.e?op=file&rev=0&sc=0) see the parse_archetype method, about 3/4 way down. It takes a while to get used to having to have more than one idea of validity, but it is almost always needed. - thomas --- ## Post #15 by @Mattias_Forss1 2007/1/17, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > Erik Sundvall schreef: > > (Related repetition: Some simple argument checking in setters might be > > OK if the community feels that this would be good. That is common Java > > culture practice and can catch a couple of bugs in a familiar manner.) > > > I could not think about a purpose for this, as the base-class setters > are only used by persistence-layers and only will be used by what has > been written by the getters to the persistence-store. Hi Bert, I don't think the setters are only used by persistence layers. There are other use cases as well. Code that creates RM objects by getting data from a user interface is an obvious example. As long as the checks are small and don't use too much resources it shouldn't be a problem of having them. You might say that when we are creating RM objects from the user interface side we do the checks after all objects have been created by calling some validation code. I think the simple checks in the setters could prove useful to detect errors at an early stage in the code instead of getting back a list of errors first after all objects have been created and the validation is done. Regards, Mattias --- ## Post #16 by @system Mattias Forss schreef: > > 2007/1/17, Bert Verhees <bert\.verhees@rosa\.nl > <mailto:bert.verhees@rosa.nl>>: > >     Erik Sundvall schreef: >     > \(Related repetition: Some simple argument checking in setters >     might be >     > OK if the community feels that this would be good\. That is >     common Java >     > culture practice and can catch a couple of bugs in a familiar >     manner\.\) >     > >     I could not think about a purpose for this, as the base\-class setters >     are only used by persistence\-layers and only will be used by what has >     been written by the getters to the persistence\-store\. > > Hi Bert, > > I don't think the setters are only used by persistence layers\. There > are other use cases as well\. Code that creates RM objects by getting > data from a user interface is an obvious example\. As long as the > checks are small and don't use too much resources it shouldn't be a > problem of having them\. > > You might say that when we are creating RM objects from the user > interface side we do the checks after all objects have been created by > calling some validation code\. I think the simple checks in the setters > could prove useful to detect errors at an early stage in the code > instead of getting back a list of errors first after all objects have > been created and the validation is done\. I thought, the proposal to which I can agree, and which made me happy was to create a base\-class\-layer with protected getter/setters\. It is not possible to use them of extern classes, because they are protected, just like Erik proposed \(POJO\-style\)\. On "top" of the base objects with protected getters/setters would be the real reference implementation, with possibly rich getters/setters, rich constructors, etc\. In my opinion, the base\-classes should have all the properties that are important from perspective of serialization\. But this is my opinion, I thought, also Eriks opinion, maybe I misunderstood regards Bert --- ## Post #17 by @system > > probably more people than Rong should be involved in contributing and > > committing code to that branch since Rong has other things to do in > > life too ;-) > > > I agree, more people should have a chance to get involved. It is good > for Rong, but also for the project. It never is good if a project > depends too much on one person. > There must be an infrastructure to let others be involved. Agree here. People get involved in open source projects in different level - testing software, reporting bugs, submitting patches, discussing ideas for new development and finally coding directly are all regarded as valuable contribution to the project. In that sense, I think you are already involved and contributing, aren't you? :-) Ultimately the Java project will need more committers other than Yin Su (Tom?) and me. But I see getting a committer right as a gradual process and I certianly think we have several good candidates on this list ;) Regards, Rong --- ## Post #18 by @system Rong Chen schreef: > >     > probably more people than Rong should be involved in >     contributing and >     > committing code to that branch since Rong has other things to do in >     > life too ;\-\) >     > >     I agree, more people should have a chance to get involved\. It is good >     for Rong, but also for the project\. It never is good if a project >     depends too much on one person\. >     There must be an infrastructure to let others be involved\. > > Agree here\. People get involved in open source projects in different > level \- testing software, reporting bugs, submitting patches, > discussing ideas for new development and finally coding directly are > all regarded as valuable contribution to the project\. In that sense, I > think you are already involved and contributing, aren't you? :\-\) > > Ultimately the Java project will need more committers other than Yin > Su \(Tom?\) and me\. But I see getting a committer right as a gradual > process and I certianly think we have several good candidates on this > list ;\) I would say, if we accomplish the base/POJO\-implementation, in the way I have written the Roadmap\-document, and we have thus the base for building different storage\-implementations, people could be given opportunity to do something with that base\. For me, I could publish the hibernate3\-layer, included hbm\-files and test\-files\.\. But I need something in return for this, else I cannot sell this to my employer\. So a good plan/deal would be \(IMHO\)\. Create a naming scheme for the base/POJO\-classes Create the POJO\-classes, so that the reference\-implementation fits on it\. If this is ready, I can publish my hibernate3\-layer, gives me also some extra time to do some tuning, and clean up some mess\. My advantage will be \(also to convince the employer\) I can reconnect to development on the reference\-implementation, this will lead to a much better and stable product\. I still will be able to use and control the databasestructure as I think it will be optimal\. Tuning of hibernate is very much depending on implementation\-purposes, etc\. We can share the knowledge, even create, f\.e\. more hibernate3 layers for different purposes Also important could be that is that the company\-name of my employer gets more exposure\. Maybe I switch also to another email\-address, and name some source\-trees to this company, in addition of se\.acode, there would also be nl\.zorggemak ;\-\) So, the sooner we start, the better\. I can help write some POJO files, it is not a lot of work, mainly deleting things\. There are a few current reference\-implementation classes which are not easy to translate to POJO\. We must rewrite the reference\-layer so it can be used together with the POJO\. I could spent an hour every day or so, for community\-based work\. And even if possible, good for my own production, more\. regards Bert --- ## Post #19 by @system Bert Verhees schreef: > ``` > Rong Chen schreef: > > ``` > > > ``` > > > probably more people than Rong should be involved in > > contributing and > > > committing code to that branch since Rong has other things to do in > > > life too ;-) > > > > > I agree, more people should have a chance to get involved. It is good > > for Rong, but also for the project. It never is good if a project > > depends too much on one person. > > There must be an infrastructure to let others be involved. > > > > Agree here. People get involved in open source projects in different > > level - testing software, reporting bugs, submitting patches, > > discussing ideas for new development and finally coding directly are > > all regarded as valuable contribution to the project. In that sense, I > > think you are already involved and contributing, aren't you? :-) > > > > Ultimately the Java project will need more committers other than Yin > > Su (Tom?) and me. But I see getting a committer right as a gradual > > process and I certianly think we have several good candidates on this > > list ;) > > > > ``` > > ``` > I would say, if we accomplish the base/POJO-implementation, in the way I > have written the Roadmap-document, and we have thus the base for > > ``` My bad English, often make small mistakes, maybe I work to hard, anmd do not pay enough attention I meant to say: ``` I meant to say, if we accomplish the base/POJO-implementation, in the way I have **read** the Roadmap-document, excuse me Bert ``` --- **Canonical:** https://discourse.openehr.org/t/java-v-s-eiffel-what-should-the-setters-do-as-mandatory-checks/14604 **Original content:** https://discourse.openehr.org/t/java-v-s-eiffel-what-should-the-setters-do-as-mandatory-checks/14604