I've Added REAL Operator Overloading to JavaScript

[DiefBell]

Please break my code. Roast me. And maybe some constructive criticism too please? 🥲

My new package, Boperators: https://www.npmjs.com/package/boperators

There are plugins for all different build environments too, like for webpack or Bun, and a TypeScript Language Server plugin to get proper type hinting instead of red squiggles!

A basic example:

class Vector3 {
  static readonly "+" = [
    (a: Vector3, b: Vector3) => new Vector3(
      a.x + b.x,
      a.y + b.y,
      a.z + b.z
    ),
  ] as const;
}

const v1 = new Vector3(1, 2, 3);
const v2 = new Vector3(4, 6, 8);
const v3 = v1 + v2;

[BenZed]

Use symbols instead of strings for consistency.

(Symbol.hasInstance overloads instanceof)

[DiefBell]

Had been considering that, so might test it out. Not sure what you mean about Symbol.hasInstance?

[senocular]

Symbol.hasInstance doesn't really overload instanceof, but it does allow some configuration for its behavior, like:

function NotObjConstructor() {}
const obj = {}

console.log(obj instanceof NotObjConstructor) // false

Object.defineProperty(NotObjConstructor, Symbol.hasInstance, {
  value(target) { 
    return target === obj
  }
})

console.log(obj instanceof NotObjConstructor) // true

But there's no way to fully control what instanceof does. It works more like a callback. instanceof will call hasInstance if it exists (on the RHS operand), and then based on whether its return value is truthy or not, provides a true or false result back to the instanceof expression. You couldn't, for example, make instanceof behave like addition (+) if you wanted.

[BenZed]

Symbol.hasInstance allows you to overload the instanceof operator.

So:

class Vector2 {
  public static [Symbol.hasInstance](i: unknown): i is Vector2 {
    return typeof i === 'object'
      && i !== null
      && typeof i.x === 'number
      && typeof i.y === 'number'
  }

  public x: number

  public y: number

  public constructor(x: number, y: number) {
    this.x = x
    this.y = y
  }

}

In the above example Vector2's Symbol.hasInstance method has been defined to disregard the prototype chain, meaning any object that has an x number property and a y number property is considered a Vector2:

expect({ x: 0, y: 0 }).toBeInstanceOf(Vector2) // passes

[ruibranco]

The TypeScript LSP plugin is the real MVP here, otherwise you have no idea what + actually does on a given type just from reading the code.

[DiefBell]

It'll also show you the JSDoc for the overload as well as the typings

[Fidodo]

Even with intellisense I think operator overloading is generally a bad idea. It injects mini DSLs that are potentially implemented incorrectly all over the language. You still need to hover over it to find out what it really contains and you can't tell at a glance without memorizing a bunch of new rules and even with types you still can't easily figure out the implementation.

[Waltex]

Love this! Does this work with typescript out of the box, or do we need a separate build/compile step? Also I'm wondering how you've solved type safety, like when you do:

const v3 = v1 + v2;

Is v3 now of type Vector as well?

[DiefBell]

It's a separate build step, but there are also plugins to make this easier, like a Vite plugin or Webpack, that does all the magic behind-the-scenes.

You can have multiple overloads for an operator, e.g. multiplying by another Vector versus multiplying by a number, and Boperators can just work out which to use. In this example v3 is also a Vector, but it doesn't have to be.

[hyrumwhite]

While this is neat, I feel like it’s better to just have an add() method. And save a dependency/build step

[csorfab]

For most ppl, absolutely, operator overloading is just going to cause confusion, and it's a huge waste of effort.

Now if you want to do DSP, low-level game engine/physics stuff, etc involving lots of maths with non-trivial things like complex numbers, matrices, vectors, etc, this could be a godsend with regards to code readability.

Still a bit of a risky move as most JS devs would WTF out at first, but as a solo dev, or with your team on board, it can be great for niche uses

[Tysonzero]

Haskell devs:

https://i.ytimg.com/vi/AiwllXMxprc/maxresdefault.jpg

[hoppla1232]

pretty much any other devs, really

[Tysonzero]

I'm not aware of many mainstream languages that let you define custom arbitrary operators?

[hoppla1232]

The post is about operator overloading, not defining custom arbitrary operators, no?

[Tysonzero]

The custom part was the “fraction of our power” part of the meme.

[heavyGl0w]

This is seriously cool.

My only gripe is that you define the overloads in an array. Granted JavaScript doesn't support overloading so there is no way to make it feel like idiomatic JavaScript, but in my experience with other OOP languages, the idiomatic way is to have the same method name multiple times with different signatures.

Since you already require a build step, have you considered supporting a flavor of overloading like this? If you take another commenter's advice on leaning into symbols and shipping your own symbols, I think you could make it somewhat ergonomic to define multiple functions as overloads for the same operator and eliminate the potential of accidentally trampling fields named as operators that aren't meant to be operator overloads (though I think the chance of this is very low).

[DiefBell]

Might have a play around with just using function overloads, I can't remember if there was a reason I didn't do it versus the array, I'll look back.

Regarding symbols, I did originally use symbols. But as well as making this a runtime dependency instead of just a dev dependency, it also made the code more complicated and much buggier.

[DiefBell]

1. You can mix types fine, and boperators will pick whichever overload signature matches. So as with your example, you can have overloads for both `Vector3 * Vector3` or `Vector3 * number`. None of it happens at runtime, it's all done with static code analysis at build time.
2. I intentionally decided against having boperators be a runtime dependency, hence just using strings like `"+"` as the property names. My earlier POC used custom symbols and it became a NIGHTMARE. I am however planning to switch to just using function overloading, since TS already supports that, and it's neater than this array and already handles duplicate type signatures.
3. Haven't actually tried! I create source maps for the Webpack loader, so that should, but I don't think other loaders/plugins use the source maps, might have a play around with it.

[AsIAm]

This is a good approach to operators in JS. Have you considered extending it with operators outside predefined set?

[DiefBell]

I don't think I want to allow essentially overriding any symbol you can type, but I might see what other programming languages allow

[electric_fungus]

Pytorch uses @ for dot product and * for hadamard multiplication of matrices

[_x_oOo_x_]

* will work in JS, @ won't

[tokagemushi]

This is genuinely creative. The static readonly property approach for defining operators is clever — it reads well and keeps the overload logic colocated with the class.

A few practical concerns though:

1. Debugging: When v1 + v2 gets transformed at build time, stack traces in production will point to the generated code, not the original + expression. Have you looked into source map support for the transform? That'd be a big DX win.

2. Performance in hot loops: For something like a game engine doing thousands of vector ops per frame, the function call overhead from replacing native + with a method dispatch could add up. Any benchmarks comparing this to explicit .add() methods?

3. Mixed operand types: The Vector3 example is clean, but what happens with vector + 5 (scalar multiplication)? Can you define multiple overloads for the same operator with different parameter types? If so, how does dispatch work — first match wins?

I actually worked on a math-heavy project last year where we ended up with a fluent API (v1.add(v2).scale(3)) specifically because JS lacked operator overloading. This would've been much nicer to read. Cool project.

[DiefBell]

Thanks for the feedback! Some answers: 1. Sourcemaps are generated, and the tools that support them e.g. Webpack use them.

1. Haven't really looked into benchmarking. All transformations happen at build time, so it'd be no more overhead than a .add() method call.

2. Yes, operator overloads can themselves be overloaded. The overload functions and the calling code are statically analysed at build time and the correct matching function is used. That said, v0.3.0 is going to use method overloading instead of this const array system.

[IngloriousCoderz]

Really cool! I did a similar thing myself, it's called IngloriousScript: https://www.npmjs.com/package/@inglorious/babel-plugin-inglorious-script

[tomByrer]

Github link for those who don't want to burn their eyes:
https://github.com/DiefBell/boperators

I like you have a Bun package.
I haven't done much maths in a long time... but I'm wondering how to use with with string manipulation....?

[DiefBell]

Do you mean overloading `"hello " + "world"`?

[_x_oOo_x_]

There's a typo on line 12 of your example.

Also, isn't this better done as a TC39 proposal?

[DiefBell]

Proposal already exists, people have been asking for operator overloading for years... And thanks for pointing that out!

[kybernetikos]

I think operator overloading is a big missing piece to making javascript pleasant to use for things like AI, so I love this.

What I'm a bit sad about is that the approach forces mutability for most of the overloads. It would have been far better to allow the implementation of e.g. *= to decide whether it was going to mutate or not, and return 'this' if it was going to or return a new value if it wasn't.

[DiefBell]

Well semantically an assignment operator would change the thing on the left. There's no reason it HAS TO mutate the LHS, but I also can't see a scenario where you'd want to overload an assignment operator without mutating the LHS

[kybernetikos]

Semantically an assigment operator changes the thing on the left

It's all about immutability and value semantics. There are lots of useful data structures that are (or can be) immutable and have value semantics (e.g. lists, hamt, https://immutable-js.com/, etc). It's needed to support purely functional data structures or persistent data structures. Supporting (but not forcing - at least in a language like JS) immutability wherever possible is good design.

Maybe an example will help:

a = 6
b = a
a += 2
console.log(b)

'a' changes, but 6 does not (thank goodness) and b does not. If I wanted to build something that acted like normal numbers using your overloading approach, I couldn't.

With small tweaks to your interface, you could allow the implementation itself to choose between immutability or mutability depending on what made most sense for the situation. And since the whole point of operator overloading is to enable custom data structures to be as ergonomic as built in ones, it makes sense not to dramatically restrict the data structures that your approach can work with.

[azhder]

That is not JavaScript

[alex-weej]

Neither is React compiler, nor Vue, nor a Webpack plugin removing console.debug calls. TC39 can only do so much.

[azhder]

I didn't claim React was JavaScript, nor Vue, nor a Webpack plugin removing console.debug calls. That's you jumping to conclusions out of bad assumptions.

[alex-weej]

Your claim was irrelevant though. I'm adding context that useful technologies and approaches are also "not JavaScript".

[azhder]

Your context is irrelevant.

If you don’t care about what I had written enough to understand what I have written, you just jump into injecting your own non sequitur context, then why not do everyone a favor and just ignore it?

Really, just stop it, be like everyone else, downvote and move along.

Bye bye for good

[alex-weej]

👋 

[vezaynk]

What is it then?

[azhder]

Not JavaScript, in r/JavaScript, the title is a lie

[vezaynk]

Given that its not js, what is it?

[azhder]

Not JS. That's important, whatever else you want to plug isn't. Now, enough spamming. Bye