Mutable java classes development kick-off

Dear all,
I’d like to let you know that I’ve just started refactoring Rong Chen’s RM implementation to create a mutable version of RM classes.
At the moment I can’t say I am following a precise, well thought out method, the term shutgun surgery is more appropriate for the current process. When I feel that the mutable version is stable and clean enough to share, I’ll immediately put it out so that others can benefit from it.
I’d like to thank Rong once again for his excellent work, which has helped many members of this community.

Kind regards
Seref

Hi Seref,

Thanks for letting us know. I definitely think this will be very
useful for the community. =)

Cheers,
Rong

Dear Seref,

Just for information, our Ruby RM implementations are mutable.
I think check the condition of parameters should move from constructor
to setter. But it is not so difficult.

Best regards,
Shinji

Hi Seref,

Please let me know when you release this library, I think it would be very useful in our openehr project.

Kind regards,
Pablo Pazos Gutierrez

Dear Shinji,
Checking the condition of the parameters can be moved to setters when the invariant depends on only one field. If the situation is more complex than that, then the classes would have to impose the order of setters.
An example is checking that a certain terminology item assigned to a dvcodedtext exists in the ontology of the archetype (or in some terminology server).
If you assign this check into setter of the dvcodedtext field, then you have to have a reference to terminology server in that particular RM instance, which means a previous setter must have been called before.
Hand written code that is handling a UI form may be coded with these constraints, but there are other use cases where you can’t impose calling order of setters.
Actually, the way the invariants are specified, invariant checking code can be quite complex. If you take a look at http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/modelling_guide.pdf you’ll see that 4.9.3 says: “Invariants must be satisfied upon completion of any creation routine.” The interpretation of creation routine is important here. If it means any routine where an RM instance is created, then a single method that validates the invariants at once feels more practical. Eiffel is probably ages ahead of many other languages for this particular requirement, but with Java, I’ll probably have to use a single method for now, and maybe duplicate certain code into setters too.

Best Regards
Seref