Proposal two:
We could add withoutBasename
withoutBasename
^ self parent
I don't see a point of this method, why not just use #parent?
This is a helper. parent is good for navigation now withoutBasename is good for manipulation of parts. It took me a while to think that I should use parent because I was looking for something else. So the problem then is a documentational one. No I do not want to read a pdf to get it.
You convinced me this library is perfect and I will keep these extensions for me. My point is, do we want to add every possible variation and helper for every use case a person can think of? I believe last year there was a lot of effort put into cleaning up String api; did String end up where it is with similar approach? I don't know, I haven't been here, that's why I am asking.
Also in other languages it is common to use `dirname` instead of parent => "asking for the directory name of what you have".
But as you point out in another thread, this is a documentational issue, and not a missing method.
I do not want to be forced to read a doc to use a system. The system itself should be discoverable and it is not in this case. This is why I will not write documentation of others code anymore.
Proposal three:
Not sure that it is worth
(note that this is not a rename)
withNewExtension: anExtension ^ self parent / self basenameWithoutExtension withExtension: anExtension
Is this somehow different than using #withExtension: directly?
Obviously since I'm with Sven one of the few persons that seem concerned with such aspect. Please, just so there is no misunderstanding. I do care about it and I am not fundamentally against it. You sent your proposals, I've added my view, and I expect other people will add theirs, so we can collectively discuss this and act on it.
You see I could have pushed this change without discussing. I can understand that proposal 3 is useless since this is the same. But the others have a value to me. Now I added them in my private extensions and this is good.
Peter