+1 norbert
Am 18.07.2013 um 13:11 schrieb Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com>: > I'm sorry to endorse the role of naughty conservatism (probably a problem of > age), but introducing a touch of damping to slow the system down don't hurt. > Anyway, any doer is responsible for his/her changes and can be prepared to > rants, > Funnily I'm also being questionned in the same time for having changed ($a > to: $z) to return a String rather than an OrderedCollection in Squeak, > We must accept that, every change is questionnable. > Personnaly I try to rationalize rants, and rationalize changes, or at least > put them in a longer term perspective, but at the end, some changes must > always be done arbitrarily. > > > 2013/7/18 Stéphane Ducasse <stephane.duca...@inria.fr> > 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. >> >> >> > >
