Resuscitating this discussion thread from last year ...
To summarize my rereading of the thread, there is good agreement that
Path.{ends,starts}With(String) should be deprecated and replaced with something
else, perhaps Path.{ends,starts}WithString(String). There was also a parallel
suggestion that Path.{ends,starts}With(Path) be deprecated in favor of
Path.{ends,starts}WithPath(Path). Thus:
* Path.{ends,starts}With(String) -> Path.{ends,starts}WithString(String)
* Path.{ends,starts}With(Path) -> Path.{ends,starts}WithPath(Path)
Among doubtlessly many others, one alternative is
1. Leave Path.{ends,starts}With(Path) unchanged
2. Deprecate Path.{ends,starts}With(String)
3. Add Path.pathString{ends,starts}With(String)
where "pathstring" in effect implies the value of Path.toString().
Comments?
Brian
On Nov 2, 2025, at 3:35 PM, David Alayachew <[email protected]> wrote:
As for deprecations, I still think all 4 methods should be deprecated. This
path variants are kind of ok, but the String variants are just too deceptively
named.
I think Rob Spoor hit it on the head with this quote.
> Perhaps both can be added?
>
> Path.{start,end}sWithString would default to calling
> toString().{start,end}sWith(arg) and
> Path.{start,end}sWithPath would default to calling
> {start,end}sWith(arg). The latter could default to
> calling {start,end}sWith(getFileSystem().getPath(arg))
> but then custom implementations that do something else
> (in addition) may not work as expected.
Doing it this way, we can have (start|end)sWithPath() have both String and Path
overloads with no ambiguity.
