[FlexJS] Removing PasswordInputBead has no effect

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
Hi,

> The wiki from 4 years ago is very helpful in understanding architectural decisions:
> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype <https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype> <https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype <https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype>>


The code I checked is as far a I can tell in line with the principal as described there:
"Everything should be "pay as you go" or "just in time" or "on demand". The current Flex framework is slow because it runs a lot of code "just-in-case". For example most mobile apps initialize a PopupManager. And other code sets up a layer for custom cursors. No need to do that unless you are really going to use it.”

There's no extra initialisation and the cost of removing the password feature is on demand.

Thanks,
Justin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
In reply to this post by Harbs
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

piotrz
Hi Justin,

Agree with you that we may not everywhere applying in PAYG manner, probably you will find more examples, but there is no point to do this. I think you can just try to fix that, cause that's what for we are here I think. :)

I'm done with those discussion in case of changes with that Bead - don't want to fight about those couple of lines. You fix one general bug I think here apart of changes in that Bead - That's good! Thank you for that!

We really need to have some system of micro voting maybe when discussion ends up on different thoughts and then die without any action or decision. As you probably see in my previous post I was trying to summarize everything and propose something, but again discussion towards to different direction. We have on the plate more such discussion and I really do not know how to end up them in order to have - "Ok we agreed how to do this - let's implement!" - Maybe discuss my concerns in the other thread please.

Piotr


Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Alex Harui-2
In reply to this post by Justin Mclean
I didn't say it was my project.  Just my vision.  And for the past 4
years, others seem to share it.  I believe that is consensus.  Bertrand
advised us many years ago to make things modular, which FlexJS is, so
folks with different opinions can go implement their opinion in a
different module.  That is the Apache Way.

Imposing your different opinion in others is not the Apache Way.

Thanks,
-Alex

On 6/5/17, 3:16 PM, "Justin Mclean" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
Hi,

> Imposing your different opinion in others is not the Apache Way.

How am I’m imposing anything here Alex? It is you that's instating that  just in time code that follows the PAYG principal as documented and that has zero practical overhead is not PAYG.

From my understanding several people are unclear of what PAYG actually is and there are several differing options on what it is. Perhaps the definition that you pointed to needs to be updated as you said it is 4 years old.

Wouldn’t it be best to document it so we can all be on the same page?

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Harbs
The definition is fine. The fact that it’s 4 years old is irrelevant.

What’s not clear once you read that doc?

Please just revert your changes and make a new bead. There’s no reason to have so much discussion on this…

> On Jun 6, 2017, at 11:18 AM, Justin Mclean <[hidden email]> wrote:
>
> Hi,
>
>> Imposing your different opinion in others is not the Apache Way.
>
> How am I’m imposing anything here Alex? It is you that's instating that  just in time code that follows the PAYG principal as documented and that has zero practical overhead is not PAYG.
>
> From my understanding several people are unclear of what PAYG actually is and there are several differing options on what it is. Perhaps the definition that you pointed to needs to be updated as you said it is 4 years old.
>
> Wouldn’t it be best to document it so we can all be on the same page?
>
> Thanks,
> Justin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
Hi,

> What’s not clear once you read that doc?


It’s unclear to me why the code I checked in isn’t PAYG as it fits with the definition of PAYG in that document.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

piotrz
I think because this bead after your changes is doing two things and you can split responsibility to the other class. - Is it enough reasonable ?

Piotr
Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Josh Tynjala
In reply to this post by Justin Mclean
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 <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Greg Dove
In reply to this post by Alex Harui-2
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >> 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
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Harbs
That would be great.

Harbs

> On Jun 6, 2017, at 10:24 PM, Greg Dove <[hidden email]> wrote:
>
> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
In reply to this post by Greg Dove
Hi,

> Actually I will have definitely 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.

I’d go further as say the definition as it is stated there seem to be perhaps too wide?

> 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.

+1 to that

> 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.

Al +1 to that. We can also point new people to it rather than trying to explain the concept(s) again saving everyone time.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

OmPrakash Muppirala
Justin,

Do you now have sufficient info on the PAYG paradigm to resolve this issue?

When you re-read Alex and Harbs' suggestions now, does it make sense?

I suggest we fix this issue and move on, please.

Thanks,
Om


On Jun 6, 2017 5:22 PM, "Justin Mclean" <[hidden email]> wrote:

Hi,

> Actually I will have definitely 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.

I’d go further as say the definition as it is stated there seem to be
perhaps too wide?

> 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.

+1 to that

> 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.

Al +1 to that. We can also point new people to it rather than trying to
explain the concept(s) again saving everyone time.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

piotrz
Agree with Om. I also do not wanna to leave this thread without any action. In whatever direction it will go.

Piotr
Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
Hi,

I'm still awaiting answers from Alex and further discussion on what PAYG is and isn’t and will resolve in accordance to that.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

OmPrakash Muppirala
It seems subclass is the way to go here.  Anyone disagree with that?

Thanks,
Om

On Jun 7, 2017 1:57 AM, "Justin Mclean" <[hidden email]> wrote:

> Hi,
>
> I'm still awaiting answers from Alex and further discussion on what PAYG
> is and isn’t and will resolve in accordance to that.
>
> Thanks,
> Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
In reply to this post by Justin Mclean
Hi,

And nothing is broken in develop and a new release (after this one) is a long way away so there’s no huge urgency here. I do intended to correct it once the discussion has died down and PAYG is clearly documented.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

piotrz
In reply to this post by OmPrakash Muppirala
Om,

You mean subclass current bead and have new functionality in the other ? If yes I'm OK.

Piotr
Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Alex Harui-2
In reply to this post by OmPrakash Muppirala
This will make the 38th post on this thread.  It is a link to the 4th post
on this thread:

https://lists.apache.org/thread.html/8f561b811d2e662769f204200eabe8bc706d97
b19f8859fe74ee9b3b@%3Cdev.flex.apache.org%3E

   "It can't be done in a subclass with
    an override of the strand setter?

    -Alex"

4 people (Piotr, Harbs, Om, me) have asked you to rework the bead.  Please
do so.

Thanks,
-Alex

On 6/7/17, 2:06 AM, "[hidden email] on behalf of OmPrakash Muppirala"
<[hidden email] on behalf of [hidden email]> wrote:

>It seems subclass is the way to go here.  Anyone disagree with that?
>
>Thanks,
>Om
>
>On Jun 7, 2017 1:57 AM, "Justin Mclean" <[hidden email]> wrote:
>
>> Hi,
>>
>> I'm still awaiting answers from Alex and further discussion on what PAYG
>> is and isn’t and will resolve in accordance to that.
>>
>> Thanks,
>> Justin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
HI,

>  "It can't be done in a subclass with
>   an override of the strand setter?

Probably not without altering the original bead which may also be not PAYG.

Thanks,
Justin
123
Loading...