Hi nicolas I agree :) So we should find the right balance. Stef
> For FileSystem, there is a clear win, so I'd say the change is really worth. > 1) you add more capabilities > 2) more logical/convenient API > 3) more efficient implementation > 4) more scalable implementation > The optional compatibility layer you offered is the exact solution to the > upgrade problem (you give a bit of time to maintainers) > I buy it. > > For and:and:and: etc... I agree with deprecation because such selector adds > near to null > (I personnally changed many senders in Squeak, so I'm totally biased here). > > For isNotNil I'm not convinced at all. > To me, it's not much but noise. > There are currently 3 senders vs 890 for notNil. I imagine many more in many > packages. > Think in mid/long term. What's your plans? Wait for the balance to slowly > inverse? Rename all? > > For notEmpty, it's worse: 6 implementors. > So what's the new contract? any new implementor of notEmpty shall also > implement isNotEmpty? > Or isNotEmpty is implemented in term of notEmpty in Object? > Currently, 5 out of 6 implementors of notEmpty do not implement isNotEmpty > and 1 out of 2 implementor of isNotEmpty does not implement notEmpty. > It's not just noise, it's currently a mess! > > As for an automated rewrite rule, yes, this is some very usefull features for > supporting such refactorings. > I'd say a pre-requisite. > But that force using several branches for cross version support, or worse, > cross dialect support. > If all diffs are automated, that's ok, if some of the changes are manual, > it's a pain (backport etc...) > > > 2013/7/17 Camillo Bruni <camillobr...@gmail.com> > 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.n...@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 <camillobr...@gmail.com> > > > >> On 2013-07-17, at 22:32, Nicolas Cellier < > >> nicolas.cellier.aka.n...@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. > > >
