On Thu, Aug 18, 2016 at 09:35:28AM +0200, stepharo wrote: Just so you don't misunderstand⦠I am not opposing those changes, I am just asking.
Proposal one:
We could add withoutExtension
withoutExtension
^ (self parent / self basenameWithoutExtension)
What is the use case for this?
To get everything except the extension. Is it not obvious? How do you did it else?
What I mean is, when would you use such method? The only use case I can see (after using FS libs for years) is to change extension, but we already have a method for that.
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.
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.
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. Peter