flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Dove"<greg.d...@gmail.com>
Subject Re: [FlexJS] Removing PasswordInputBead has no effect
Date Tue, 06 Jun 2017 19:24:52 GMT
Alex, and Harbs,

Thanks for pointing that out. Actually I will have defifintely looked through this early on,
but I'd have to say it is quite 'light' on what PAYG actually means beyond the general sense
that I had. It does have some more detail about beads which is great and I could have benefited
from revisiting that in recent months which I did not do. 

But I can see that the newly created 'DRY' discussion thread is actually creating the type
of content that I think I would have found really helpful in terms of linking a guiding concept
to one of its key implementation areas. 

Creating this type of documentation is *hard*. Not just because creating the content itself
is a lot of work, But also because it is not (usually I think) something that a developer
wants to do, especially when volunteering their time. "I'd much rather be coding". So thanks
Alex for what you already created there.
However, I think the contents of the new thread look really good as something that could be
used as a resource to define bead variation in terms of PAYG adherence, as an implementation
guide, and I do think we really need this.

If there's that level of clarity and, ultimately, agreement in terms of definitions and approaches,
I expect there will be far less need for threads like this one.

If no-one else volunteers to wiki-fy the contents of the new thread at its conclusion, I will
give it a shot over the coming weekend.

On 2017-06-06 18:55 (+1200), Alex Harui <aharui@adobe.com.INVALID> wrote: 
> 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.dove@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.lists@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 <justin@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
> >>
> >>

View raw message