Okay, so PAYG can't have One True Definition. How you implement PAYG depends on context.
I wonder if some kind of PAYG pattern cookbook would be helpful? I was thinking that our situations with PAYG remind me of software design patterns. Design patterns aren't really defined with an exact implementation, but they offer guidance for how you can solve problems of a certain category. With PAYG, I think we're going to have different categories that will need similar implementations, but not exactly the same. That's where PAYG patterns could help provide a framework for implementation. Let's find common patterns. Maybe even give them names to make them memorable and easy to refer to. - Josh On Thu, Jul 13, 2017 at 10:42 AM, Alex Harui <aha...@adobe.com.invalid> wrote: > Hi, > > I promised some feedback on Greg's PAYG page. After thinking about it > some more, I'm proposing my take on it below. I know past discussion > tried to break off component set definitions from PAYG, but I think PAYG > is always going to be subjective enough that the goals of the various > component sets will affect decisions about what goes in the default beads. > I can't say this often enough though: one main goal of beads is to avoid > spending energy on what is the one right way, and also, on exactly what > PAYG means. If you don't agree with what PAYG means to the others working > on a component set, go start a new component set. > > So, I am going to try to discuss all of the related factors in one place > below. > > Thanks, > -Alex > > --- Pay-as-you-go (PAYG) --- > > > PAYG means that Download Size, Startup Time, Memory Usage, Line of Code > goes up and Performance goes down as new features are added to the > Application. > > PAYG leverages well-known computer science principles: Re-usable code, > Separation of Concerns, Modularity, Abstraction. > > PAYG cannot be defined objectively. You can be too granular or not > granular enough. > Too Much: Put a for loop in a re-usable function. Everybody must call > this function. > Too Little: Regular Flex SDK. 13,000 line base classes. > Just Right: Make it possible that an application has no unused code paths > in the framework code it uses. IOW, no just-in-case code. > > FlexJS uses modules called "Beads" to implement features in a PAYG > fashion. Beads are placed on Strands so composition is primary pattern. > > PAYG has no required implementation patterns. There is no one right way. > Subclassing, sharing utility functions, beads sharing other beads are all > valid implementations. The key is to see how it measures up against the > metrics of Download Size, Startup Time, Memory Usage, etc. Other > computer-science principles like DRY should be considered as well. There > doesn't have to be only one version of a bead. There can be beads with > different implementations and tradeoffs on those metrics. > > ---Additional Guidelines for FlexJS--- > > Naming: Pick a relatively small/simple set of features that are likely to > be used in several applications. Give it a name starting with Simple, > or something descriptive and well-known like Panel. Additional features > expand the name with prefixes (DropDownList instead of ListForDropDown) or > suffixes like PanelWithControlBar. Reduced/inlined versions will also get > expanded names. > > Defensive Code: Rarely needed. Bad inputs should be found and fixed > before deploying the app. Folks who take the time to do that should be > rewarded with smaller code and faster performance. Use of goog.DEBUG to > have debug-time input checking is allowed. There is a trade-off between > any performance hit of debug-time checking vs the developer productivity > of having those errors caught early. > > Bead Removal: We may someday decide that beads should almost never be > removed. Implementing a flag to disable a bead might be cheaper than > removing it. > > Component Sets: Different component sets have different goals. > Basic: smallest SWF-equivalent implementations > Express: Pre-package Basic beads and thus SWF-equivalent > MDL: No interest in SWF equivalence. > > JS metrics are more important than SWF metrics. > > >
