-
Notifications
You must be signed in to change notification settings - Fork 10
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
Extensibility considerations #24
Comments
That's a good question. The issue with the open type is, of course, that we lose all exhaustiveness checks (so you risk meeting an error at runtime). Passing an I'm not in favor or removing type ext_view = ..
type view =
| Empty
| Text of { … }
| Extension of ext_view and then make |
I think this sounds like a sensible approach. |
I could implement this (eventually) because I have a use-case for it: flame graphs. Questions to consider before resorting to extensions:
|
Hi,
First of all, thank you for such a great library!
I wonder if you guys have considered an extensibility story for printbox. I know you've made
t
opaque andview
private in 0.2 (I am not 100% sure about the reasoning here) but have you thought about allowing end-users to add their own constructs ift
was made extensible instead (I guess that would makeview
go away?)Where printers like
text
orhtml
would have a way to pass a handler for a catch-all match that is not handled by the library itself? Something likeThe text was updated successfully, but these errors were encountered: