> >Instead one is forced to write: > >context Person inv: > >wife->notEmpty() implies wife.gender = Gender::female > >which is not only counter-intuitive (Person.wife is not defined as a Set >of anything, it is defined as a Person), but seems wrong because there is >no formal connection between whatever Set the expression "wife->" refers >to and the underlying model, so how can one say anything about what the >membership of this set might imply for the value of the Person at the >other end of the wife association?
but it's worse than this in practice. if wife is null, therefore wife->isEmpty is true. Therefore wife.Gender = Gender::female is true, because there is no wife in the list that breaks this constraint. This is not intuitive but is an inevitable conclusion from the use of wife->notEmpty() to specify that wife != null. Obviously it's safe if you write inv: not (wife->notEmpty()) and (wife.gender = Gender::female) but most people wouldn't think of doing this and would simply write inv: wife.gender = Gender::female expecting that this would only be true if wife.Gender actually was Gender::female Grahame - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
