Nogcmacro

[kkoopa]

Tried to remove the dependence on macros.
The gc callback thing feels a bit clumsy.

[agnat]

The gc callback thing feels a bit clumsy.

I see you pulled the direct call trick ... other than that. Please elaborate...

[kkoopa]

I would like to get the callback as a function argument, like in all other parts of the API, but that is not possible. This will remain a slightly odd case.

On October 10, 2015 1:13:19 PM GMT+03:00, David Siegel [email protected] wrote:

The gc callback thing feels a bit clumsy.

I see you pulled the direct call trick ... other than that. Please
elaborate...

---

Reply to this email directly or view it on GitHub:
#489 (comment)

[kkoopa]

Yeah, this is all mostly for the next major, whenever that is. Not worth breaking compatibility over these small things alone. Just figured I'd explore the possibilities. This seems to be the best way of defining callbacks when no arbitrary data arguments are available.

[kkoopa]

The ugliness could be avoided by using a static map of gc callbacks, but I don't know if it is worth it.

[agnat]

Hm, yeah... a homegrown v-table... not sure... in my book that would be even more ugly as it introduces a call overhead of O(n log(n)) (I think) with n being the number of NAN based modules. Not that anyone would notice but I like the template version better...

[agnat]

BTW, I don't think it's ugly... it's merely a bit inconsistent. Actually I think I like it. The pattern has interesting properties.

[kkoopa]

This would only be for the gc callbacks. There n would grow with the number of gc callbacks. How likely are you to use many of such an obscure item? Inconsistency is arguably ugliness, but I prefer this over macros. C++11 lifts a lot of these restrictions, but we can't use that everywhere yet, which is kind of limiting.