This was first published in 2012. https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
PAYG and avoiding just-in-case code is mentioned in that document. As are Beads. Thanks, -Alex On 6/5/17, 11:33 PM, "Greg Dove" <greg.d...@gmail.com> wrote: >Harbs, a quick comment from the sidelines on: "PAYG is already well >understood" > >I don't really think that is the case, at least it has not been for me. I >had a more general notion of PAYG that was nothing to do with beads at >all, >and was limited to guesswork/my own interpretation of it at the beginning >because there was no clear definition. > >Unless this is documented somewhere then I believe it is actually a >barrier >(of understanding) for people getting involved. If there's already a >difficulty with 'thinking this way' and 'acting this way' as you indicated >when you had started and had understood it, then it seems important that >it >should also be easily understood in the first place in order to make >things >easier for people wanting to participate. > >As with a lot of things, once you 'know' it you can tend to take if for >granted that everyone else does too. But I think you already hinted at >that >with what you said... > >I am of the opinion that 'vision', 'mission', 'goals' and even >'architecture' etc don't really exist in a form that is useful for shared >understanding unless they are documented in some way. And no, 'it's >obvious >from the source code' is not what I mean :). >They are not considered to do so in many other scenarios, in any case, and >I can't understand why it would be different in an open source project, >although I definitely have not spent time comparing projects to find out >what others do here. > > >On Tue, Jun 6, 2017 at 5:21 PM, Harbs <harbs.li...@gmail.com> wrote: > >> We’ve all already been implementing things as Alex states. He >>architected >> the framework and it’s a good architecture. No need to change things. We >> need consistent architecture. We can’t have a free-for-all... >> >> Percentage of code really has nothing to do with it. Unless something is >> functionality that you would (virtually) always need, it’s a separate >>bead. >> That’s the way the whole SDK is implemented. If there are cases where >>it’s >> not, it’s a bug and should be fixed. Removal of password functionality >>is >> NOT usually required for password beads. >> >> PAYG is already well understood: All functionality should be implemented >> as beads when practical. Beads should be as modular as possible with the >> smallest possible functional set. >> >> That’s pretty much it. It’s difficult to make the mental switch to >>working >> this way. I had similar difficulty when I started implementing things >>for >> FlexJS. It takes some getting used to, but it’s a very good design. >> >> Harbs >> >> > On Jun 6, 2017, at 1:16 AM, Justin Mclean <jus...@classsoftware.com> >> wrote: >> > >> > Hi, >> > >> >> If you have a different vision, you can execute that vision in >>another >> >> component set or fork FlexJS entirely. Please do not impose your >>vision >> >> on my vision. >> > >> > Since when is this your project Alex or that the project has to only >> include your vision? That is not the Apache way. >> > >> > I would prefer that we all come to a consensus of what PAYG means and >> clearly document it rather that you dictating it. >> > >> > Thanks, >> > Justin >> >>
