4 ms·

Operator overloading, what a great idea?

by metafunctor 5y ago

freemint 5y ago
Operator overloading is a great idea but compared myadd2 or add_fractions a + is way more readable.
- lionkor 5y ago
  more readable, but not easier to understand. a = a + b still carries the same information as add_and_copy(a, b), but one is misleading and the other isnt.
- ordu 5y ago
  > a + is way more readable. I believe it works much like a self-fulfilling prophecy. Language designers think that it is more readable, so they do it. Language users use it and became habituated to it. So it becomes more readable because some people believe that it is more readable. What is unreadable with: a.extend(b) c = a.clone().extend(b); Programmer have all the control of memory management, and at the same time she is free to do any operations on lists, to chain operations, to do everything. And all her intent is here, it is written, it is obvious. While a += b... It leads to a need to write articles describing the difference between + and += and how could I possibly know did programmer who wrote the code read all such articles? Did he wrote he intended to, or what is nicey looking, but not great semantically? Did I read all these articles or I missed something? Even if it is more readable, does it justify all the obscurity?
  - account42 5y ago
    Do you also believe all built-in types like integers should use named functions instead of operators?
    - ordu 5y ago
      No. I even believe that non-builtin types behaving like numbers might use operators. But lists, arrays, strings behave not like numbers. They allocate memory, they reuse memory for values, they have operations of non O(1) complexity, and so they shouldn't be using operators. If one really wants to, then he might invent new operators for this, like concatenation-operator. I didn't see any reasonable way to do it, but it doesn't mean that such way cannot be devised.
      - c-cube 5y ago
        Numbers in python also allocate memory. Integers are arbitrary precision, so the difference between + and += might also be very relevant for them. And of course there's numpy and matrices which also behave like numbers, or at least like mathematical objects.
- metafunctor 5y ago
  Only if you know what + happens to mean. Which, it turns out, you sometimes don't. It's especially bad when you think you know what it means, but you're mistaken. I was kind of joking, of course, but only kind of. I'm a happy user of operator overloading.
  - maleldil 5y ago
    I don't see how that's any different from normal method calls, though. If you don't know what `a + b` does for an arbitrary type, why would you know what `a.add(b)` does? Overloaded operators and methods are all just operations on a type.
    - tialaramex 5y ago
      Convention. Like the core of language itself. If you refuse to respect convention we can't communicate. You ask about a.add(b) but notice that's also using two operators. First it needs a . operator for member access. Languages rarely allow you to overload this operator because doing so makes your head hurt, but there's no reason in theory it couldn't exist. [In Python we can use __getattribute__ to meddle with this, but to avoid infinite recursion we can't use __getattribute__ to meddle with the operator overloading, such as __getattribute__ itself... ] Second you need a () operator to call the member. This you can sometimes overload, for example in C++. So what this does might be defined by that operator overload. The only way to avoid this being too confusing to use is to obey conventions, and even once you do that many of the operator overloads will be rarely needed and one wonders whether to just abolish overloading them. Worse, unlike a function call, operators sometimes come with other semantic expectations that may be impossible to enforce. For example the operators && and || are short-cutting logic booleans, in almost any programming language with such an operator, in_cache(foo) || slow_check(foo) only performs slow_check(foo) when in_cache(foo) was false. But an overload can't ensure this! Instead both will be evaluated and the results provided to the operator overload function, too late to optimise. Overloading should be used very sparingly. If any significant fraction of your users find your overload confusing, it was a bad idea. Better than ten people wonder why they must write a.add(b) than that one person writes a + b and then is completely astonished by what you decided that does.
alisonkisk 5y ago
Operator overloading is the same as having the same method "add" for different types.
- metafunctor 5y ago
  Yep. The IDE could resolve types (with the help of the compiler, perhaps), and tell you what the code you wrote actually does.

Operator overloading, what a great idea?

freemint 5y ago

Operator overloading is a great idea but compared myadd2 or add_fractions a + is way more readable.

lionkor 5y ago
more readable, but not easier to understand. a = a + b still carries the same information as add_and_copy(a, b), but one is misleading and the other isnt.
ordu 5y ago
> a + is way more readable. I believe it works much like a self-fulfilling prophecy. Language designers think that it is more readable, so they do it. Language users use it and became habituated to it. So it becomes more readable because some people believe that it is more readable. What is unreadable with: a.extend(b) c = a.clone().extend(b); Programmer have all the control of memory management, and at the same time she is free to do any operations on lists, to chain operations, to do everything. And all her intent is here, it is written, it is obvious. While a += b... It leads to a need to write articles describing the difference between + and += and how could I possibly know did programmer who wrote the code read all such articles? Did he wrote he intended to, or what is nicey looking, but not great semantically? Did I read all these articles or I missed something? Even if it is more readable, does it justify all the obscurity?
- account42 5y ago
  Do you also believe all built-in types like integers should use named functions instead of operators?
  - ordu 5y ago
    No. I even believe that non-builtin types behaving like numbers might use operators. But lists, arrays, strings behave not like numbers. They allocate memory, they reuse memory for values, they have operations of non O(1) complexity, and so they shouldn't be using operators. If one really wants to, then he might invent new operators for this, like concatenation-operator. I didn't see any reasonable way to do it, but it doesn't mean that such way cannot be devised.
    - c-cube 5y ago
      Numbers in python also allocate memory. Integers are arbitrary precision, so the difference between + and += might also be very relevant for them. And of course there's numpy and matrices which also behave like numbers, or at least like mathematical objects.
metafunctor 5y ago
Only if you know what + happens to mean. Which, it turns out, you sometimes don't. It's especially bad when you think you know what it means, but you're mistaken. I was kind of joking, of course, but only kind of. I'm a happy user of operator overloading.
- maleldil 5y ago
  I don't see how that's any different from normal method calls, though. If you don't know what `a + b` does for an arbitrary type, why would you know what `a.add(b)` does? Overloaded operators and methods are all just operations on a type.
  - tialaramex 5y ago
    Convention. Like the core of language itself. If you refuse to respect convention we can't communicate. You ask about a.add(b) but notice that's also using two operators. First it needs a . operator for member access. Languages rarely allow you to overload this operator because doing so makes your head hurt, but there's no reason in theory it couldn't exist. [In Python we can use __getattribute__ to meddle with this, but to avoid infinite recursion we can't use __getattribute__ to meddle with the operator overloading, such as __getattribute__ itself... ] Second you need a () operator to call the member. This you can sometimes overload, for example in C++. So what this does might be defined by that operator overload. The only way to avoid this being too confusing to use is to obey conventions, and even once you do that many of the operator overloads will be rarely needed and one wonders whether to just abolish overloading them. Worse, unlike a function call, operators sometimes come with other semantic expectations that may be impossible to enforce. For example the operators && and || are short-cutting logic booleans, in almost any programming language with such an operator, in_cache(foo) || slow_check(foo) only performs slow_check(foo) when in_cache(foo) was false. But an overload can't ensure this! Instead both will be evaluated and the results provided to the operator overload function, too late to optimise. Overloading should be used very sparingly. If any significant fraction of your users find your overload confusing, it was a bad idea. Better than ten people wonder why they must write a.add(b) than that one person writes a + b and then is completely astonished by what you decided that does.

alisonkisk 5y ago

Operator overloading is the same as having the same method "add" for different types.

metafunctor 5y ago
Yep. The IDE could resolve types (with the help of the compiler, perhaps), and tell you what the code you wrote actually does.