On Mon, Jan 18, 2010 at 4:24 AM, Stanislav Muhametsin
<[email protected]> wrote:
> OK, it's been a while and I've been awfully busy, but now I've put up a
> proposition for "post-constraints", which were discussed in December 2009.

Ok, let's set this up as a discussion for post-1.0...

> 3. Why not (Motivation against)?
> Possible overhead (due to extra checking). Possible syntax-confusions (see
> below).

Ok, the overhead is "developer choice" so I think I am Ok with it.
Syntax-confusion is the problem, and possibly not worse than other.

> 4. How?
> All methods must by default return non-null value, same as with method
> parameters.

Yes, this is probably important as a default.

> If the method has concerns or side-effects, post-constraint should be
> executed before returning back to concern and (therefore) before executing
> side-effect. It makes more sense with this + concern can't modify the result
> of the method in between.

Ahh! No, Concerns are allowed to modify return values. And this raises
a problem.
If the post-constraint contract is "for the composite", we would need
to execute "after" the method is completed, BUT if there then is a
violation, wrapping concerns should probably know about it. So, by the
sounds of it, it needs to sit "in between" different concerns. Perhaps
it is possible to implement the whole concept with Concerns and clever
use of the Invocation annotation, meaning it would be a library
separated from Core.


> If the overhead of these is too much, there could be added some kind of
> "usePostConstraints" -switch to Qi4j runtime.

That would be cool.


Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev

Reply via email to