Hopefully this fixes #59. I've tested it by building the docs and they seem to run correctly.
Fable 3 mangles members of abstract classes by default. This is kind of a breaking change and we may revert it at some point, but I think using interfaces for the bindings is cleaner here so if you don't mind @cmeeren we can merge this and publish a new version to make things compatible with Fable 3 (it will still work fine with Fable 2). Reasons why interfaces are preferred:
Cleaner code, you don't need the attributes AbstractClass and Erase and all members are abstracts, there are no a couple of member inline outliers.
Emit can be used directly on interface members and it also inlines the code, so it has the same effect as member inline.
In the case of Breakpoints I'm using extensions instead with AutoOpen. This shouldn't break consume code.
cmeeren
commented
3 years ago
Hopefully this fixes #59. I've tested it by building the docs and they seem to run correctly.
Fable 3 mangles members of abstract classes by default. This is kind of a breaking change and we may revert it at some point, but I think using interfaces for the bindings is cleaner here so if you don't mind @cmeeren we can merge this and publish a new version to make things compatible with Fable 3 (it will still work fine with Fable 2). Reasons why interfaces are preferred:
AbstractClassandEraseand all members are abstracts, there are no a couple ofmember inlineoutliers.Emitcan be used directly on interface members and it also inlines the code, so it has the same effect asmember inline.BreakpointsI'm using extensions instead withAutoOpen. This shouldn't break consume code.