Add an option to handle overloaded constructor parameters

Bug #1501896 reported by Alexandre Abreu on 2015-10-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Add way to handle overloaded constructor parameters instead of a unique set_constructor.

JavaScript doesn't have function overloading. Calling add_constructor() on your v8cpp::Class object will enable the "new X" call from JavaScript, but you can only export one constructor definition that way. That is a limitation the JavaScript language enforces, not us.

The only way to overload a function is to define a new function that takes a FunctionCallbackInfo<Value> argument and reroute the call according to which arguments were provided. Again, this is analogous to JavaScript.

This is the reason for those factory style new_*() calls I used in the example. The other option would be to derive new classes from all those that have overloaded constructors, and define a constructor for the child that takes in the FunctionCallbackInfo<Value> argument. But we will quickly hit dead ends this way with classes that are declared "final".

This is why my thinking was that we standardize on the factory style construction (new_*() functions) for all classes to keep things consistent across the board.

Changed in v8-cpp:
status: New → Incomplete

Hmm, just remembered, we hit the same dead ends with "final" classes when binding overloaded methods.

For classes with overloaded constructors, perhaps defining a new class with a constructor that takes a FunctionCallbackInfo<Value> is not such a bad idea. We could derive from base Scopes classes for non-final types, and use the "has-a" relationship for those that are.

Either way, we should standardise on either factory-style construction, or new-style construction, rather than a mixture of both.

Yes I know that js does not have overload caps, but I was thinking of a more general mechanism that would ease up the process of mapping a factory like (new () being just an instance of it) construct similar to what you mentioned,

What you described (FunctionCallbackInfo<Value> constructor params & has-a) is exactly what I ended up doing, but it is indeed a bit heavy and would be handy to have it automatically done in v8-cpp (hence my "bug").

I am not sure that mixing construct mechanisms is the best things to do. we should make things as uniform as possible,

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers