On Jul 18, 2013, at 1:11 PM, Nicolas Cellier
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 abou
+1
norbert
Am 18.07.2013 um 13:11 schrieb Nicolas Cellier
:
> 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
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
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 com
On Jul 17, 2013, at 11:03 PM, Camillo Bruni wrote:
> 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.
I do not think that this is the same because and:and:and: were not real
On Jul 17, 2013, at 10:32 PM, Nicolas Cellier
wrote:
> So you would be ready to change notNil -> isNotNil and become a bit more
> incompatible with the rest of the world?
> I understand that the pair isEmpty/isNotEmpty may seem a bit more
> homogeneous, but I see no other selector constructed
On Jul 17, 2013, at 10:33 PM, Nicolas Cellier
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
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 gi
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
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
> On 2013-07-17, at 22:32, Nicolas Cellier <
>
On 2013-07-17, at 22:32, Nicolas Cellier
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, b
So you would be ready to change notNil -> isNotNil and become a bit more
incompatible with the rest of the world?
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 w
30276
-
7300 Finder raise an error on asking for implementors
https://pharo.fogbugz.com/f/cases/7300
10348 GroupAlreadyExists vs. GroupsAlreadyExists confusion
https://pharo.fogbugz.com/f/cases/10348
11180 Add a filter to the config browser
https://pha
13 matches
Mail list logo
