Re: Design by Contract

> I still don't see what's wrong with just putting the code at the beginning of the function and whenever you want to check it That makes inheritance of contracts awkward/impossible/impractical: class Some { public function method() { assertOrWhatever($expr); } } class Other extends Some { public function method() { } } The implementation of Other::method cannot inherit or otherwise make use of the contracts made by Some. Putting invariants in the class scope and pre/post conditions in the function prototype makes inheritance relatively easy. This seems to answer all your questions. Cheers Joe On Wed, Feb 11, 2015 at 7:11 AM, Joe Watkins <pthreads@pthreads.org> wrote: > > I think reusing syntax for existing operator in completely unrelated > context is a big mistake. > > I keep hearing that, I agree, but adding keywords presents it's own > problems. > > The keywords can always be changed, maybe they can be a voting option even. > > Cheers > Joe > > On Wed, Feb 11, 2015 at 6:56 AM, Stanislav Malyshev <smalyshev@gmail.com> > wrote: > >> Hi! >> >> > Please steer clear of using the assert API, and in so doing avoid BC >> > concerns with the current assert API. >> >> The operator can be called something other than "assert", I'm sure the >> thesaurus has a lot of possibilities. >> >> > Please avoid adding a magic method and use the suggested syntax for >> > invariant. >> > >> > class Some { >> > require(invariant-expr); >> >> I think reusing syntax for existing operator in completely unrelated >> context is a big mistake. Having code outside of functions is probably >> not the best idea too. >> >> -- >> Stas Malyshev >> smalyshev@gmail.com >> > >