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 <philippe.marschall@netcetera.ch> 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