operator overloading is good, but getters and setters are not · riki's house

hey! looks like you have JavaScript disabled.
I respect that decision, but you may find the experience of browsing the treehouse… not great.
for example, links to branches may not work properly. I cannot do anything about this; it's due to how the <details> element works.
(a <details> will not expand itself automatically to reveal the linked element to you.)
I did my best to at least keep the site readable in this state, but you can only do so much with plain HTML and CSS.

Pinky promise this website does not contain any malicious code such as trackers or cryptocurrency miners.
if you don't believe me, you're free to inspect the source yourself! all the scripts are written lovingly in vanilla JS (not minified!) by yours truly ❤️

and if this box is annoying, feel free to block it with uBlock Origin or something. I have no way of remembering you closed it, and don't wanna add a database to this website. simplicity rules!

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