Seeking philosophical guidance on library interface design.

[Richard Gaskin]

R is among the world's most popular tools for this.  When in doubt, 
following their proven popular designs would seem a good bet.

R's plot function is a thing of beauty.

Their default is to produce the most commonly-used result. You can even 
pass nothing but data to it and get a very useful result.

Using named vars (which in LC may make more sense as an array), each arg 
you add to the call overrides one of those defaults.

The range of options is vast.  No one expects you to even attempt them 
all of course, but if you adopt this model it may make it easier for 
others to add property overrides as needed.


To get you started, their docs and a brief tutorial:

plot function | R Documentation
https://www.rdocumentation.org/packages/graphics/versions/3.5.3/topics/plot

Producing Simple Graphs with R
https://www.rdocumentation.org/packages/graphics/versions/3.5.3/topics/plot

-- 
  Richard Gaskin
  Fourth World Systems


Alex Tweedly wrote:
> I'm building a library (which I plan to release as Open Source), and I'm 
> having trouble trying to decide which approach to take with default values.
> 
> The library is to produce XY graphs (charts). An app which is using it 
> will provide one or more sets of data to be plotted. The app can also 
> *optionally* provide additional parameters, such as
> 
>   - display tick-marks on each axis
> 
>   - display grid lines along each axis
> 
>   - label the ticks / grids (e.g. display label every 5 ticks)
> 
> etc.
> 
> Without going into each one of them, there is an overall "phlosophy" chioce
> 
> A - should the default be that the produced graph be simple (e.g. no 
> ticks, no labels, etc.)
> 
> or
> 
> B  - should the default be to try to find reasonable / possible values 
> (e.g. set a value for ticks such that they appear, say, more than 10 
> pixels apart, but less than 100 pixels apart; that you label every 
> 2nd-5th tick, ...)
> 
> A is appealing because it means that the library isn't making guesses, 
> often dumb guesses, on your behalf; you see a blank, sparse graph, and 
> can then, as app developer, provide additional parameters to supply info 
> you think will help. But it is unappealing because the graphs are just 
> *so* empty by default.
> 
> B is appealing because it feels like it is being helpful, and will (try 
> to) produce a reasonable looking graph as best it can.
> 
> 
> So - I'd welcome any suggestions, comments, design philosophy ideas ?
> 
> Thanks
> 
> Alex.
>