Seeking philosophical guidance on library interface design.

[Dar Scott Consulting]

I'm not sure what C is.  Maybe something related to using arrays.  Maybe a tool to create code snippets.  

> On Apr 25, 2019, at 2:25 PM, Alex Tweedly via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Sorry, but .. what is C ?
> 
> Current plan is kind of  B-      i.e. the default is to try to apply some simple guesswork to make a "reasonable" looking result, but with a simple way (e.g. put TRUE into myArray["NoGuessing"] ) to prevent any such attempt and ave a minimal, undecorated graph.
> 
> -- Alex.
> 
> On 25/04/2019 19:29, Dar Scott Consulting via use-livecode wrote:
>> Coming in late...
>> 
>> For bread-and-butter code, B.
>> 
>> For software development, A.
>> 
>> But, really, my response is C.
>> 
>> Dar
>> 
>> 
>>> On Apr 23, 2019, at 5:01 PM, Alex Tweedly via use-livecode <use-livecode at lists.runrev.com> wrote:
>>> 
>>> Hi folks,
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>