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@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@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@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
