Hi, I was just referring to post-conditions as a platform for discussion at a theoretical level. I am not very good with UML either, but vaguely recall that pre-conditions mapped more or less 1-1 with our constraints.
Because then the question would arise; if we end up with 1-1 relationship with pre/post conditions, should we then have the same naming? Anyway, let's continue without such considerations... Constraints consists of two parts, the annotation and the implementation. The annotation is easily positioned where it makes sense for parameters. But for a return value, we only have the whole method as a choice. Does this make sense? @Identifier String identifyNextToken(); Secondly, in-argument constraints are really a tool to ensure that "users" of a piece of code doesn't throw invalid values at it. What is the primary purpose of out value checks? As a documentation tool to such user it would be great, but does it really help if there is a violation in runtime, which would indicate an internal error (bug) in the codebase that one uses. Is it worth the runtime overhead of such constant checks? Or is it simply a matter of a giant Qi4j.enablePostConstraints( boolean on ) switch? -- Niclas On 3 Dec 2009 20:04, "Stanislav Muhametsin" <[email protected]> wrote: Quoting Niclas Hedhman <[email protected]>: > On Thu, Dec 3, 2009 at 5:40 PM, Stanislav Muhametsin ... About implementation - extending interface sounds more easy and straightforward. As long as it wouldn't create any abnormal situations and won't confuse the constraint implementator too much, IMO that sounds like a better idea. About theory - I'm not 100% familiar with UML post-conditions. Most definitions I know and the ones available on Internet, seem to include the internal state to both pre- and post-conditions. Because we are talking about Qi4j Constraints, and they don't have access to internal state, we can leave out the internal state when talking about pre- and post-conditions. I think the internal state conditions can be expressed in Concerns, since Concerns have access to internal state, and the composite implementator is aware of all Concern implementations his/her composite has. Hence constraint post-condition evaluation could consist of analyzing return value only. However, do you think that sometimes it is also required to analyze input parameters (for possible changes) along with return value? I mean, technically speaking, if pre-conditions cover method input, post-conditions should cover both input AND output. Would that get too complicated and confusing for users of Qi4j? _______________________________________________ qi4j-dev mailing list [email protected] ht...
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
