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
