there have been many similar decisions in the past, I remember for instance the move from #and:and:and: or #or:or:or: which weighs around the same as the #isNotNil. FileSystem or Slots are even on a bigger scale. Package maintenance in which sense, across different Pharo versions or different Smalltalk versions? Between Pharo versions should be more or less ok, since such changes (#isNotNil and Co) usually come with a proper deprecation. AFAIK there is someone working on detecting much more subtle changes in Pharo and provide lint rules on top. So I think we have to embrace changes. On 2013-07-17, at 22:49, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
I wonder what is the decision process behind such change. Do you put in balance what you gain and what you loose? To me gain is near zero and these little changes stacked together put a useless burden on package maintenance.
2013/7/17 Camillo Bruni <camillobruni@gmail.com>
On 2013-07-17, at 22:32, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
So you would be ready to change notNil -> isNotNil and become a bit more incompatible with the rest of the world?
that method is already present in the image.
I understand that the pair isEmpty/isNotEmpty may seem a bit more homogeneous, but I see no other selector constructed with (isNot isnt) while I see many others where is is omitted. I wonder what this kind of change really serve...
For me they are consistent with all the other is* methods out there returning booleans.