Non-null by default is very easy to implement. Would we then require @Optional to mark that it may or may not return a value?
Then there is a pattern of NullObjects (I think Kent Beck is credited for that one), where null is outright not allowed and certain semantics are given to such singleton of the right type. -- Niclas On 4 Dec 2009 18:15, "Stanislav Muhametsin" <[email protected]> wrote: Quoting Rickard Öberg <[email protected]>: > On 2009-12-04 00.29, Stanislav Muhametsin wrote: ... Indeed! And a very good one, because we don't always want to expose all our internal state to every possible check there is :) >> However they are much simpler and >> easier to use, and the composite doesn't NEED to have @Con... Don't think I know enough about Qi4j philosophy to properly comment on that one. :) > That would seem to be one reasonable return-value constraint. Any others > which are not better done... > > > Agreed, and for the particular case of null-checking it would make sense. > Any other cases??? > > Well, looking at Qi4j Constraints library, I think there pretty many (if not all) constraints, which could be applied to method output. @NotEmpty, @GreaterThan, etc etc. However, then it should be decided how to handle null return values. Should the null return value be ok? Then there would be a slight 'schizophrenia' in Qi4j, regarding null input values and null output values. But then again, would it be too much to make them non-null by default? _______________________________________________ qi4j-dev mailing list [email protected] h...
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
