As of now, the backends are enumerated with a sum type and each backend has flexibility of choosing a context structure and whatever methods it finds fit.
I don't like the idea of having multiple context containers (e.g. in the case of cairo we have 3 nested things that we could name ctx).
With module functors, the API we expect from backends will become more well-defined. Recently too, I have been trying out using Joy and adding different backends. I also attempted to add it on the browser (https://kaustubh.page/joy.ml/) with an SVG backend. e.g. with a REPL, it's convenient to have a clear function.
One part I'm not sure of is the API for getting the result - we may want to write to a file (PNG), or get it as a string (SVG), or write it to a DOM element (Canvas / SVG in the browser). How do we accommodate these use cases into our API?
https://github.com/Sudha247/ocaml-joy/pull/98 proposes the addition of Module functors.
As of now, the backends are enumerated with a sum type and each backend has flexibility of choosing a context structure and whatever methods it finds fit.
I don't like the idea of having multiple context containers (e.g. in the case of cairo we have 3 nested things that we could name
ctx).With module functors, the API we expect from backends will become more well-defined. Recently too, I have been trying out using Joy and adding different backends. I also attempted to add it on the browser (https://kaustubh.page/joy.ml/) with an SVG backend. e.g. with a REPL, it's convenient to have a
clearfunction.One part I'm not sure of is the API for getting the result - we may want to write to a file (PNG), or get it as a string (SVG), or write it to a DOM element (Canvas / SVG in the browser). How do we accommodate these use cases into our API?