operator overloading is good, but getters and setters are not

this one stems from an argument I had today, so I’ll write my thoughts for future generations’ enjoyment here
2024-02-12
I’ll start by prefacing that I think operator overloading is good iff it’s implemented in a way that a single operator has only one, well-defined meaning
2024-02-12
- this means + really means addition and nothing else.
  2024-02-12
  - this is practically impossible to enforce at a language level - what prevents the standard library authors from overloading + to mean string concatenation after all?
    2024-02-12
    however we can at least do our best by writing good defaults and coding standards that gently suggest what to do and what not to do
    2024-02-12
    for example, allow users to define their own arbitrary operators that are explicitly not addition, to incentivize inventing new syntax for these things
    2024-02-12
  - the way I’d like to do it in my dream language is by a few means
    2024-02-12
    (+) is defined to be a polymorphic operator which calls into a module implementing the AddSub interface, which means you have to implement both addition and subtraction for (+) to work on your type
    
    let AddSub = interface { type T fun add (a : T) (b : T) : T fun subtract (a : T) (b : T) : T } fun (+) (a : let T) (b : T) : T use AS : AddSub with { T } = AS.add a b
    2024-02-12
    note how this operator does not have any effects declared on it - this means addition and subtraction must not have any side effects such as I/O
    2024-02-12
    the (add AND subtract) rule enforces types like strings to take a different operator, because (-) does not have a well-defined meaning on strings
    2024-02-12
    is "foobar" - "bar" == "foo"?
    2024-02-12
    by extension, is "foofoobarbar" - "bar" == "foofoobar" or "foofoobarbar" - "bar" == "foofoo"?
    2024-02-12
    maybe characters are subtracted from the left string one by one? such that "foobar" - "bar" == "\x04\x0e\xfcbar" (wtf)
    2024-02-12
so now getters and setters: what’s so bad about them?
2024-02-12
- the problem is that given the rule above - one operator means one thing - getters and setters completely destroy your assumptions about what = might do
  2024-02-12
  - what’s that? you didn’t expect camera.angle_z = 420 to throw because 420 is out of the [-π/2, π/2] range? oops!
    2024-02-12
  - what’s that? you didn’t expect camera.angle_z to return a different value every time you access it? oh, well!
    2024-02-12
    at least when it’s spelled camera.angle_z() it suggests that it might do something weird, like access the thread RNG.
    2024-02-12
- not to mention all the infinite recursion annoyance that sometimes happens when implementing them manually
  2024-02-12
  - this is less of a problem in languages that feature automatic generation of getters and setters - such as Kotlin
    
    var someVariable: String get private set // no infinite recursion to be seen here!
    
    but it’s still an issue in e.g. JavaScript, where one mistake can send your call stack down the spiral:
    
    class Example { #someVariable = ""; get someVariable() { return this.someVariable; } // typo!!!! set someVariable(value) { this.someVariable = value; } // typo again!!!!!!!!!! dammit! }
    
    and the error is not caught until runtime.
    2024-02-12
    it’s easy to fix but still an annoyance whenever you write a getter/setter pair.
    2024-02-12

© riki moe / リキ萌

    \    /
   | \__/ |
 \ /      \ /   ___
--|  _  _  |-- =_  \
 / `------` \    \  \
     |   \        |  |
     |    \      _/  |
    /      |    /  _/
   |        \  / _/
   |         |__/
   \-,,-,,--/