-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow OVERRIDE wrappers to chain. #28
Comments
v1.3.6.0 implements the first syntax: libWrapper.register("module-a", "Foo.prototype.bar", "OVERRIDE", {chain: true}); I chose the first syntax to avoid needing messy backwards compatibility code. Same change also adds a test for this syntax. This API is not documented yet, pending Better Rolls using it, in case we need to change it. It will be considered public soon. |
Reopening just to track the Better Rolls updates, and update the documentation. |
This is now documented in v1.4.0.0, and Better Rolls has been updated. Closing. |
The module "Better Rolls" has an interesting use case. It is, by default, a full override. As such, it uses "OVERRIDE". However, if the caller passes a specific parameter, it wishes to call the original method.
Because OVERRIDE by default doesn't provide the
wrapped
chain object, they are forced to use private APIs to access the_wrapped
method instead. In addition to being unsupported, this will soon become impossible due to the work for #16.In the original API design, OVERRIDE didn't provide the
wrapped
chain object on purpose. This was to avoid people using OVERRIDE just because they wanted to be the last module called, even when they weren't truly overriding a method. However, I failed to realise that there is a very rare use case where such a module might wish to call the original method.An optional solution that does not compromise the API's design goals and maintains backward compatibility is to take an optional
chain
parameter that, iftrue
, provides thewrapped
chain object regardless of the wrapper type:Optionally, the third parameter could be replaced by the dictionary (only when not a string, for backwards compatibility), e.g.:
The text was updated successfully, but these errors were encountered: