On 2/28/17, 5:52 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > >> It isn't wrong, it just may not be what you need for your app. If you >>add >> a property that has to be checked, that's a bit more code than making >> assumptions about what kind of overflow you want. > >AFAIKS it's less code and less of a maintenance issue. If I copy those >400 lines of code as suggest and if the code changes in one file then it >needs to change in the other, that can easily get out of sync and cause >issues.
Yep. There are trade-offs. Feel free to create a base class for shared code if that helps. There is additional overhead for base classes as well, so eventually someone will publish and maintain two copies of 400 lines because the likelihood of it changing is low. The key point is giving people choices. We don't want to require someone to have to use the configurable version if they don't need it. > >> In the end for scrolling beads, I expect there will be one tuned to just >> vertical. One tuned to just Horizontal. > >Which is fine but we don't have that yet. I’m a strong believer in >getting it to work first, then optimise it, premature optimisation wastes >time and often makes incorrect assumptions. Oh good, then you are onboard with us just getting one kind of vertical scrolling to work and worrying about other kinds of scrolling when someone finally needed it. Thanks, -Alex
