The way that beads work means that we will frequently "violate" DRY, as I understand it. FlexJS is designed to have multiple beads that implement the same thing in different ways. The simplest bead will be designed to be never removed and it probably won't include any properties to configure its behavior. A more complex bead might include some of the same code from the simplest bead, but it will also be designed to be removed, but still not configured. An even more complex bead will include all three (the core feature, removal, and properties to configure). There might even be a fourth one that can't be removed, but has properties to configure. Going even further, there might even be variations with different subsets of properties that can be configured.
Ideally, we'd find a way to reuse some of the code from the simpler beads. It might be possible to subclass them, for instance. However, unless the simplest beads are designed for it, reusing their code may not be possible. In fact, designing them in a way that they can be extended may violate PAYG instead because it may require adding code that isn't always needed. In that case, there's no option except to repeat some code. - Josh On Tue, Jun 6, 2017 at 12:02 AM, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > > > Unless something is functionality that you would (virtually) always > need, it’s a separate bead. > > So for CCS we have border, does everyone need borders? Why do we only a > sub set of the font attributes included? Some people are not going to use > all of them or in fact any of them and some other may need other properties > so why are they not seperate? Not that I think these should be removed > into seperate parts. The issue is just about every feature you can name is > going to optional to someone. So I think we near a clearer definition of > what PAYG is. > > Another example why for instance was flexGrow and flexShrink added in to > the CSS code? Shouldn't they be implemented in line with the PAYG principal > in another class? And there are numerous other examples of this. I feel > that PAYG is not being applied consistently and seems selective on who is > making the contribution. > > > PAYG is already well understood > > IMO it has not been clearly defined. Alex has described in various ways as > it size / runtime cost only to move to goal posts. I for one would like a > clearer definition of it. > > > All functionality should be implemented as beads when practical. Beads > should be as modular as possible with the smallest possible functional set. > > What about the cost of violating DRY or the single responsibility > principal which two beads do similar things? Is it really OK to add > technical debt / penalise users of a new feature when it would be less cost > modifying/improving an existing bead at a much smaller cost? How do you > discourage copy paste coding? > > Thanks, > Justin
