Operator overloading ?

[BrothaOnAcid]

Is there any plans/possibility to add some kind of 'extension' for this syn. sugar ? It would be very useful in vector/matrix math n stuff =]

Here is an example:

function Vec2(x, y)
{
    this.x = x;
    this.y = y;
}

var a = new Vec2(5.0, 2.5);
var b = new Vec2(2.3, 1.0);

var c = a + b; // special ADD function would be called 

[svaarala]

I guess it would be relatively straightforward to add some custom behavior to the basic operations so that when they operate on objects, they'd detect and invoke custom methods. For instance, if the left argument to an 'add' operation had __add__ it would get called with 'b' as its argument and the return value would become the expression value.

I'm not sure if such extensions would be very useful, though, as part of the usefulness of Ecmascript is that there are multiple engines, etc. Because this kind of extension cannot be easily emulated with pure Ecmascript (or even C code in most engines I guess), it would cause some undesirable lock-in.

[darkuranium]

That might be true, but OTOH, Duktape has a different purpose to most other engines (for starters, it's lightweight, and meant to be embedded in just about anything --- and that "anything" is unlikely to swap an engine out anytime soon).

Perhaps you could leverage proxy objects if you don't want to deal with the ops directly? It would ensure that nobody can create __add__ by accident by doing

// for when some runtime str == "__add__" by completely random chance (or malicious input)
foo[str] = ...

Interestingly, my primary use case for this is exactly the use case @BrothaOnAcid mentioned. I'd love something like that for my game engine bindings:

// pos, vel are Vec2
// += could be __addeq__
this.pos += this.vel * dt;

It's usually important to keep += separate, as it might make sense in some cases where the operation can be far more efficient; perhaps rewrite a += b into a = a + b when __addeq__ does not exist / fails?

Though __radd__ or similar might also be a good idea (for after __add__ fails). Consider this use case:

// float * vec2 instead of vec2 * float; and there's no __add__(vec2) in float.
this.pos += dt * this.vel;

[avih]

While arguably useful, this is not javascript... I don't think it'd be a good idea for Duktape to introduce unique new language features...

[markand]

I agree with @avih, we should not start implementing features that are not from the ECMAScript standard.

[kphillisjr]

@avih and @markand, I personally believe that some Non-Standard features are a good idea to introduce. How about for starters to limit this to custom objects defined using C/C++ only.

[avih]

It's not my project so it's not my decision to make, but I still think it's better to not introduce non standard language features or non standard syntax/sugar.

[svaarala]

Like I said above I'm not very excited about adding operator overloading because it's not really Ecmascript then anymore. But if overloading support was added, I'd find it awkward if it was only available for C/C++ code: most current mechanisms allow either kind of function to be called (Ecmascript or Duktape/C) so that you can implement e.g. finalizers in either C or Ecmascript, whichever suits your application best.

[JoshEngebretson]

I really wouldn't like to see anything that could possible affect Ecmascript compatibility or introduce any side effects. We're running Javascript, TypeScript, CoffeeScript, Haxe, etc on top of Duktape and compatibility is tremendously important to us.

Where additions are appreciated is in stuff like coroutines, which don't affect the langage spec

[svaarala]

@JoshEngebretson Agree, breaking compliance is not an option. One could add operator overloading by introducing the overload methods as internal properties (later private symbols) which wouldn't affect compliance for any code that didn't explicitly want to use them.

[kphillisjr]

I did not say that the feature should be enabled by default. It is also a good possibility that this behavior could be changed in future versions of ecmascript. This is why it can be sectioned off into a custom build define.

[BrothaOnAcid]

O ya, i agree with @kphillisjr ! Why not to extend Duktape with some extra features thru disabled-by-default-precompiler-defines . Something like #define DUK_ENABLE_OP_OVERLOADING for those who don't care about ecma-compatibility in their projects. ;)

[fatcerberus]

...I'm just going to ignore this, pretend it doesn't exist and hopefully it'll go away... ;)

Operator overloading in JS, eugh. Just the thought makes me cringe.

[svaarala]

@fatcerberus On the other hand several Ecmascript features provide "operation" overloading (if not operator overloading). For example, getters/setters are essentially overloading the semantics of property lookups which is very convenient and avoids the boilerplate getter/setter method issues common in e.g. Java; ES6 Proxy also traps several common operations, including function calls and object construction.

What I would like to avoid, if possible, is creating new "front end" mechanisms which might not align well with future ES developments and wouldn't be available in other engines. I don't mind custom "back end" mechanisms; for example, adding a direct C binding for creating efficient Proxy objects would be OK, because anyone using that could still port their code to another engine as the front end concept (Proxy) would be the same.

[markand]

I'm still against adding non-ecmascript features. Duktape is ECMAScript engine not JavaScript++. And adding more code for non-standard features even with a compiler tunable is still sucky because it complexify again and again. Less is more.

[avih]

Less is more.

As if Ecmascript is not "more" enough ;) especially ES6...

[markand]

As if Ecmascript is not "more" enough ;) especially ES6...

But operator overloading is not present in ES6, I would like to see ES6 support in Duktape obviously, but not features that are not part of the specification.

[avih]

I would like to see ES6 support in Duktape obviously, but not features that are not part of the specification.

Obviously. Same here.

[dy]

This is an outdated issue, but here's example implementation from QuickJS https://github.com/justjake/quickjs-emscripten/blob/master/quickjs/tests/test_op_overloading.js.