The issue now is that there are several plotting packages, each with advantages and disadvantages, forcing users to make a choice often from limited information. I'm afraid defining another plotting API in Base, rather than simplifying the matter, will just create another choice you'll have to evaluate. It pains me to reference xkcd 927 <http://xkcd.com/927/>, since it's so often over-applied, but it seems applicable here.
Simon's example of defining show functions for vaguely graphical types could be useful if it's kept simple, but the more complicated/featureful it becomes, the more it will start to exasperate the problem. On Thursday, January 22, 2015 at 7:42:37 AM UTC-8, David van Leeuwen wrote: > > Hello, > > I've just read up on most recent conversations mentioning plotting, after > I went through a similar install-and-try-out cycle for the various plotting > packages. > > I am busy with a package named ROC <https://github.com/davidavdav/ROC> > (Receiver > Operating Characteristic). It is mostly about decision cost functions and > efficiently computing ROC statistics, but there is also some support for > making various plots related to the ROC. > > I do not want to decide for a potential user of this package which > plotting package she should use. So it would be nice if there would be an > abstract plotting API (I suppose this does not exist yet). > > Supposing that it is possible to make an API that includes some common > plotting primitives, and that makes a runtime selection based on > `isdefined(plottingpackagename)`, how would you > - overload a function, typically `plot()`, when at module-include time it > is not yet known which plotting package the user wants > - specify the dependence of this package to any one of the available > plotting packages. > > Thoughts? > > Thanks, > > ---david >
