While I agree that we shouldn’t unnecessary make life more difficult for external frameworks/libraries when that can be avoided, we do have to reserve the right to be able to make changes that break things.
Like with #includesSubstring: the actual intention of the change is valid and sound, but the process could have been smoother. Issue 11876 does have a point and it does simplify the system, IMHO. On 24 Oct 2013, at 08:17, Philippe Marschall <[email protected]> wrote: > On 22.10.13 00:08, Camillo Bruni wrote: >> see my long explanation here >> https://pharo.fogbugz.com/default.asp?11876#87218 >> it looks unsuspicous until the moment you try understand such a failing >> assertion. > > This isn't moving Pharo foward. This doesn't make the system any more > flexible, adaptable, modular or malleable. This doesn't make the system any > easier to maintain. This doesn't make the system any smaller, faster, > scalable or secure. This doesn't make the system any easier to maintain. This > doesn't make life easier for anybody developing Pharo or using Pharo. This > doesn't improve Pharo in any way. > > This only adds code who's sole purpose is to break people's existing code. > > If you disagree with such a way of writing tests then the right solution IMHO > is to write a SLint rule. > > Cheers > Philippe > >
