Extensibility considerations

[cmxog]

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 and view 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 if t was made extensible instead (I guess that would make view go away?)

type t = ..

type t += TitledFrame of (string * t)
type t += MyWidget

Where printers like text or html would have a way to pass a handler for a catch-all match that is not handled by the library itself? Something like

 PrintBox_text.to_string ~extension_handler box

[c-cube]

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 extension_handler is of course doable.

I'm not in favor or removing view but it could have an open case:

type ext_view = ..

type view =
  | Empty
  | Text of { … }
  | Extension of ext_view

and then make extension_handler optional?

[cmxog]

I think this sounds like a sensible approach.

[lukstafi]

I could implement this (eventually) because I have a use-case for it: flame graphs. Questions to consider before resorting to extensions:

1. Can the functionality be layered on top of printbox in a backend-independent way? Then there's no need for making it an extension.
2. Can the functionality be layered on top of printbox in the text backend, but not e.g. in the html backend? That's the case with plotting -- I can use printbox-text as a canvas. If I migrated it to an extension, I could use vector graphics when the output is html -- but if I wanted to implement an html backend for plotting, I can do it outside of printbox.
3. Can the functionality be upstreamed to printbox? Flame graphs cannot be easily layered on top of printbox -- need to store span measures inside tree nodes. But it seems too specific of a gadget to be upstreamed?