If I saw a method called endsWithString, I'd be inclined to call
path.endsWithString(".html"), which is what started this entire thread.
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.
On 18/09/2025 20:38, Brian Burkhalter wrote:
If Path.endsWith(String) and possibly Path.startsWith(String) were to be
deprecated, then perhaps something like Path.{start,end}sWIthString(String)
could be replacements?
Brian
On Sep 18, 2025, at 11:19 AM, Rob Spoor <[email protected]> wrote:
If Path.endsWith(String) and possibly Path.startsWith(String) are deprecated,
can we then get Path.endsWithPath(String) and Path.startsWithPath(String) as
replacements? Because having to type
path.endsWith(path.getFileSystem().getPath(other)) is not only a lot more
verbose but my IDE also complains that I don't close the result of calling
path.getFileSystem() (which of course I shouldn't), so I have to suppress the
warning.
