On 21/09/13 10:08, Claude Warren wrote:
There are several methods listed in the Model and ModelCon interfaces that
return the model for chaining purposes.
I want to test that the model is returned.
Assuming the a method call:
Model m = // create a model
Model m2 = m.f(x)
I believe the requirement is for
m2 == m to be true
Same here - if the contract is also:
m.f1() ;
m.f2() ;
m.f3() ;
has the same effect as m.f1().f2().f3() then i don't see theer is mouch
choice other than m2==m.
A similar requirement is for items created on the model be "of" the model
(not necessarily in the model). For example ModelCon.createStatement(
Resource, Property, String ) should return a statement such that
Model m = // create model
Statement s = m.createStatement( Resource, Property, String )
should return a statement such that the statement is not in the model
(m.contains(s) == false) but is of the model (s.getModel() == m)
The question is should the second test be s.getModel() == m or
s.getModel().equals(m)?
Isn't Model.equals same as == anyway? As model can be large, it seems
to me there isn't much choice from a practicality standpoint.
There is one case getAlt()
Model m = // create model;
Alt a = m.getAlt( Resource );
where both a.getModel() == m and a.getMode().equals(m) are false. However
a.getModel.isIsomorphicWith( m ) is true.
I believe that in both cases the correct tests should be
m2 == m
and
x.getModel() == m
Comments?
Weird - where in the code base is a different model being created?
And is method-chaining broken?
m.getAlt(...).add(...)
vs
m.getAlt(...)
m.add(...)
Claude
Digression:
Is this the right time to split the Model-API (APIs?) from the core
graph-level machinery into a separate module?
Andy
