On 7 Jan 2026, at 12:34, Brian Burkhalter wrote:
> 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?
$0.02 – I like it. I think David and Pavel have pointed out
a legitimately significant "sharp edge" in the API, where it is
too easy to read /foo.startsWith("bar")/ and read that as a string
operation. But it isn’t.
(Any other string-like methods out there? Any other /foo/ that
responds to /.startsWith("bar")/ but does something different
from /foo.toString()/?)
Olexandr’s observation about factoring the string ops via
Path::toString is also spot-on. However, it’s not a cure-all,
especially given the "false friend" methods already in Path.
I would suggest that, if we add new "true friend" methods in
Path, that they should say something like "this is the same as
calling /toString().startWith(x)/ but may be more efficient".
Javadoc does (at least) two useful things at the same time:
It A. makes it easier to discover useful API points, and B. teaches
you how to use both those API points and related ones. The very
presence of Path::endsWithString (or whatever) makes the
useful API point (A) discoverable, but then it can also suggest,
(B) "hey, did you consider calling toString first?".
— John
