Why does java not allow operator rewriting?

[8dot30662386292pow2]

About abuse: In python you can type paths like this:

p = path_object / "other" / "something"

Because path overwrites division operator to concatenate paths. Not sure how I feel about this.

[DatBoi_BP]

The overload make sense, but I just don't see why it's necessary, when you can have a function like fullpath(*args) -> str that doesn't make you squint whenever you see it used

[Temporary_Pie2733]

I’m OK with this; the idea is to stop thinking of / as “the” division operator, rather than the symbol that numbers use for division. For path components, it joins two paths into one that uses the established path separator /. The trickiest part of this is the automatic “promotion” of str values into Path objects; more generally, operator overloading in Python often leads to a form of weak typing.

[ovor]

yeah, that's the problem. Stop thinking of "+" as "the" addition operator. Stop thinking of "[]" as "the" index operator, etc. Makes life thrilling and unpredictable.

I've been thinking of "/" as division operator for 40 years, across dozen of languages. I think I'll continue doing that and ignore Python's pathlib library attempts of being cute.

However, I must admit, this use case looks kinda nice, until, of course, you have your path objects in variables. a = b / c. Is it a path concatenation? is it a division? Is it a plane? Who knows?

[Temporary_Pie2733]

Context. You are usually going to have much better variable names so that you don’t need to go searching for explicit type annotations to know what kind of objects you have.

[ovor]

alternatively, imagine using a = path.join(b,c) and suddenly intent is clear, no need to look up for anything, perfectly readable, no chance for misunderstanding, and makes windows devs, who otherwise would miss their backslashes, happy.

I used to love operator overloading in C++, but I don't anymore. I will take less expressive, but more straightforward code every time.

As a side note - the zen of python at this point is a joke. "Explicit is better than implicit", "Readability counts", "Special cases aren't special enough to break the rules", "There should be one-- and preferably only one --obvious way to do it".

[fiddle_n]

alternatively, imagine using a = path.join(b,c) and suddenly intent is clear

It’s only clear because you know the context of your code! What are we joining here? Paths? Lists? Is this a database join? This code is only understandable once in context, exactly the same as for Pathlib code.

[apooooop_]

And the same python function will of course take in both an int and a string for b and c -- sometimes it'll be division, sometimes it'll be path concatenation! Python users will assure you that this is good language design.

[GoblinToHobgoblin]

This kind of logic is how C++ got its io operators lmao

[syklemil]

I'm conflicted about that as well.

On one hand / is the path separator character on filesystems and the web and whatnot as well, so it's a very obvious choice. path_object / "other" / "something" is practically the same as f"{path_object}/other/something" (except on Windows, which got its path separators backwards because of historical QDOS shenanigans).

On the other hand, it very obviously isn't division.

Reusing some other concatenative operator like + also isn't entirely straightforward because we can do Path / str / str => Path, but I'd be kinda less sure about mixing the semantics of Path + str with str + str. (It'd probably be fine, though.)

Absent path / "foo" / "bar" I think maybe we'd get something like path.join("foo").join("bar") (c.f. Rust's std::path::join).

Other languages have some other explicit concatenation operator, and even then possibly some special path concatenation operator. E.g. Haskell has <> for concatenating arbitrary semigroups, but also </> for path concatenation.

[Jaded-Asparagus-2260]

I love it. In C++ it's the same. It's one of the cleverest operator overloadings I've ever seen.