Mattias mentioned that the two of you (MF+RC) had chatted about the
issue that the parent is set null instead of the real parent in the
AOM by the parser. I now had a look at the RMObjectBuilder and found a
similar issue. Is it not so that RM objects that inherit from
Locatable should know (have a reference to or be able to look up)
their parent if they have one (i.e all non root objects)?
A question to Tom:
Why is parent optional (0..1) in the spec, is it only because root
nodes don't have parents or is it because parent can be ignored by
implementations? Maybe some text and possibly an invariant statement
in the spec could make this more clear?
I guess the RMObjectBuilder should be the right place to attach
children and parents?
If you add the two code lines below to the end of the method
testBuildComposition() in the unit test class
org.openehr.build.EHRBuildTest you will find the error by the last
test.
assertEquals("section", section(), composition.getContent().get(0));
//passes fine
assertEquals("parent", composition,
composition.getContent().get(0).getParent()); //fails
I might have misunderstood things here, but I guess that one in
addition to constructors has to use the protected setter setParent()
(inherited from Locatable) during the build process.
This also brings me to the question if the current java-ref-impl
implementation strives for strong or weak immutability?
Mattias mentioned that the two of you (MF+RC) had chatted about the
issue that the parent is set null instead of the real parent in the
AOM by the parser. I now had a look at the RMObjectBuilder and found a
similar issue. Is it not so that RM objects that inherit from
Locatable should know (have a reference to or be able to look up)
their parent if they have one (i.e all non root objects)?
A question to Tom:
Why is parent optional (0..1) in the spec, is it only because root
nodes don't have parents or is it because parent can be ignored by
it's mainly because of the reason being discussed elsewhere - it cannot
usually be sensibly supplied on creation.
implementations? Maybe some text and possibly an invariant statement
in the spec could make this more clear?
Mattias mentioned that the two of you (MF+RC) had chatted about the
issue that the parent is set null instead of the real parent in the
Yes, now I think I will go for no “parent” in the constructor + addChild() solution (thanks for the tip, Tom).
AOM by the parser. I now had a look at the RMObjectBuilder and found a
similar issue. Is it not so that RM objects that inherit from
Locatable should know (have a reference to or be able to look up)
their parent if they have one (i.e all non root objects)?
A question to Tom:
Why is parent optional (0..1) in the spec, is it only because root
nodes don’t have parents or is it because parent can be ignored by
implementations? Maybe some text and possibly an invariant statement
in the spec could make this more clear?
I guess the RMObjectBuilder should be the right place to attach
children and parents?
If you add the two code lines below to the end of the method
testBuildComposition() in the unit test class
org.openehr.build.EHRBuildTest you will find the error by the last
test.
assertEquals(“section”, section(), composition.getContent().get(0));
//passes fine
assertEquals(“parent”, composition,
composition.getContent().get(0).getParent()); //fails
Thanks for reporting this. It will be on the to-do list.
Right now, updating the AOM and the parser; the work on rm-builder will start later preferably with input on common kernel API.
I might have misunderstood things here, but I guess that one in
addition to constructors has to use the protected setter setParent()
(inherited from Locatable) during the build process.
This also brings me to the question if the current java-ref-impl
implementation strives for strong or weak immutability?
