flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: [FlexJS] Removing PasswordInputBead has no effect
Date Tue, 06 Jun 2017 06:55:38 GMT
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
>>
>>

Mime
View raw message