Personnally I sometimes want to break the contracts because I know that I
don't need them and can optimize some performance-critical operations.
A good example is Fraction.
The invariants are:
numerator isInteger and: [denominator isInteger and: [
denominator strictlyPositive and: [numerat
Is this not the classic problem solved by design by contract (as in
Eiffel)? Deciding who must check for errors (sender or receiver) and
specifying it formally (the contract) is more important rather than who
SHOULD check.
I found
http://forum.world.st/Run-time-checking-with-design-by-contract-ass
On Fri 30 Aug 2019 at 09:34, Julien wrote:
> Hello,
>
> I opened that issue: https://github.com/pharo-project/pharo/issues/4442
>
> And I think to fix it we need to actually discuss about what we want.
>
> #allButFirst: behaves differently depending on the actual type of
> sequenceable collection
over breakfast Santiago was suggesting that we have
allButFirst:ifOutOfBounds:
and he said that having an exception is important because you want to know if
we get data data or not.
And in that case the client will have to check all the time.
Stef
> On 30 Aug 2019, at 11:56, Ben Com
On Fri, 30 Aug 2019 at 15:34, Julien wrote:
> Hello,
>
> I opened that issue: https://github.com/pharo-project/pharo/issues/4442
>
> And I think to fix it we need to actually discuss about what we want.
>
> #allButFirst: behaves differently depending on the actual type of
> sequenceable collectio
