> 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 <pthre...@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 <smalys...@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
>> smalys...@gmail.com
>>
>
>
