In an attempt to simplify the pattern, can we say: Strands = components Beads = functionalities
All components dont need all functionalities. We add functionalities to components on a Pay As You Go (PAYG) basis. This is achieved through composition (the classical OOP paradigm) That is, a Strand is composed of several Beads. Beads are added to Strands only when necessary. That leaves us with how we build the Beads themselves. I suggest we encourage inheritance for Beads so as to follow the Dont Repeat Yourself (DRY) principle. Thanks, Om On Jun 6, 2017 8:03 AM, "Alex Harui" <aha...@adobe.com.invalid> wrote: I agree we have to be concerned about DRY. Research into optimal patterns for creating common flavors of beads would be very helpful. The compiler might be able to help as well. -Alex On 6/6/17, 6:52 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: >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
