Actually I'm not sure it's at all sane to try to override contracts, I'd actually avoid that completely, so no need to name contracts and no need for magic __invariant.
Cheers Joe On Tue, Feb 10, 2015 at 7:26 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi Dmitry, > > On Tue, Feb 10, 2015 at 4:21 PM, Dmitry Stogov <dmi...@zend.com> wrote: > > > 4) regarding the error message second argument to the condition > >> definitions, it would be useful to have these not only as plain > >> (extrapolated) strings, but as full expressions-that-evaluate-to-string. > >> That would permit hooking to arbitrary private logging and log > formatting > >> methods. > >> > > I don't think we will implement this. It may be proposed later as a DbC > > extension. > > > > I thought it works just like assert(), but no problem for me. > > > > 5) and a bit off-topic, it would be useful to be able to declare (sic) > >> whole methods to be nonproduction only: Methods that will only be used > in > >> pre/post/invariant condition expresions (or error formatters a la my > point > >> 4) > >> > > this is also not directly related as well. > > Sorry, but we should define realistic target to be able to provide a > > working solution. > > We can't think about all possible and indirectly related features at > once. > > > > I agree. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net >
