Quoting Niclas Hedhman <[email protected]>:
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.
Aah, well, I'm only familiar with theoretical pre/post -conditions as
mathematical expressions, which must hold true before/after certain
code, respectively. But those map really clumsily / badly into most of
the current programming languages.
Imo Qi4j-Concerns can be both pre- and post-conditions of a method, as
it is possible to evaluate expressions before and after calling a
method, and throwing exceptions if necessary. Constraints only can
implement subset of functionality of Concerns, since they can't access
internal state nor return value. However they are much simpler and
easier to use, and the composite doesn't NEED to have
@Constraints(...) for every constraint used in there, as it does for
Concerns.
So from pre/post -condition perspective, Qi4j is a little fragmented
as Constraints can be used for certain part of pre-condition
functionality (performing static checks for input parameters), and
Concerns can be used for ALL pre/post -condition functionality (can
evaluate any expression, as it has access to internal state).
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?
If so happens, then definetly. From my own experiences, those terms
are taught more often in educational institutes. However, of course, I
don't really have a broad experience of those. :)
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();
Hmm, depends what you mean by @Identifier. If it can be done without
internal state checking, then sure. I had something like this in my
mind:
@NonNullResult
String identifyNextToken();
Now, whoever uses identifyNextToken() method, can always assume that
the result he gets from this method is always non-null, as it will be
ensured by the framework (assuming the composite doesn't override
default implementation).
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?
To ease up the work of whoever uses the code. At least I am far more
impressed by
@NonNullResult
String identifyNextToken();
than
/**
* This will never return null.
*/
String identifyNextToken();
Basically, this case is all the same thing as described in Constraints
tutorial page, first paragraph ( http://www.qi4j.org/151.html ). Also
ease up the work of whoever implements identifyNextToken() method, and
would make debugging easier too. Yes, both pre/post conditions are
perfectly possible with Concerns, but doing it with Constraints would
simply be easier and more elegant and less dependant on
mixin/concern/side-effect binding of actual composite, and more
constraint-oriented.
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
Imo in all bug scenarios, the sooner the bug is noticed, the better.
Suppose there is an internal error in codebase, and it returns some
illegal value. Then we store it in some object for a while, and at
some point, use it, or even worse, pass it on somewhere else. So
either bug can be detected there, or it stays hidden until something
actually uses the value. And by then, it will be hard to track (in any
non-simple application).
Whether it is actually worth the overhead, that depends totally on
application and its goals. I'm not sure if adding post-constraints
would really add that much overhead into whatever Qi4j already has.
And making some thing optional (for example by that
enablePostConstraints(...) switch), is always kinda tricky. It usually
tends too easily to end up all the people just disabling switch.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
