Seeking philosophical guidance on library interface design.

Alex Tweedly alex at tweedly.net
Thu Apr 25 16:25:34 EDT 2019


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




More information about the Use-livecode mailing list