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.

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 <camillobruni@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.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.

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.ducasse@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 <camillobruni@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.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.

On Jul 18, 2013, at 1:11 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

I'm sorry to endorse the role of naughty conservatism (probably a problem of age),

No this is good to have people to kick our ass and I like because you are not blunt and your arguments are well funded to me. So there is no problem about 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.ducasse@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 <camillobruni@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.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.

On Jul 17, 2013, at 10:33 PM, 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?

I will not be changed. I just added isNotNot in addition to notNot. No deprecation, no refactoring. Marcus