Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)
From: Harbs <harbs.lists@gmail.com>
In-Reply-To: <CACK5iZe1i71+bE_6qfgjXDoUBOqrQO6vm+Hgkb0F19SrJ-bdew@mail.gmail.com>
Date: Tue, 6 Jun 2017 23:31:43 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <24FF0747-F3FF-40DC-B53B-E36BD216168C@gmail.com>
References: <D55C1124.93D39%aharui@adobe.com> <CACK5iZe1i71+bE_6qfgjXDoUBOqrQO6vm+Hgkb0F19SrJ-bdew@mail.gmail.com>
To: dev@flex.apache.org
archived-at: Tue, 06 Jun 2017 20:31:59 -0000

There=E2=80=99s actually two ways of adhering to DRY:
1. Subclassing
2. Utility classes.

In FlexJS we have a preference towards utility classes. (and I=E2=80=99d =
like to see even more) Besides very often doing a better job than =
subclasses in terms of avoiding code-repeat, it=E2=80=99s also more =
geared towards functional programming which is a good thing. It allows =
for easier testing and the like. Lots of small utility classes is also =
much more modular.

So, utility classes solves PAYG, DRY and improved testability. An all =
around win=E2=80=A6

As far as beads go vis a vis subclassing, I=E2=80=99d say it depends:
1. The the vast majority of the functionality could be in utility =
classes, then I=E2=80=99d go for two separate classes.
2. If two versions of the same bead-type are unlikely to be used in the =
same app, I=E2=80=99d avoid subclassing as well.
3. If it=E2=80=99s likely to have both versions of the beads in use and =
utility classes are impractical, I=E2=80=99d lean towards subclassing.

My $0.02
Harbs

> On Jun 6, 2017, at 6:52 PM, OmPrakash Muppirala <bigosmallm@gmail.com> =
wrote:
>=20
> In an attempt to simplify the pattern, can we say:
>=20
> Strands =3D components
> Beads =3D functionalities
>=20
> All components dont need all functionalities.  We add functionalities =
to
> components on a Pay As You Go (PAYG) basis.
>=20
> This is achieved through composition (the classical OOP paradigm)
>=20
> That is, a Strand is composed of several Beads.  Beads are added to =
Strands
> only when necessary.
>=20
> That leaves us with how we build the Beads themselves.  I suggest we
> encourage  inheritance for Beads so as to follow the Dont Repeat =
Yourself
> (DRY) principle.
>=20
> Thanks,
> Om
>=20
>=20
> On Jun 6, 2017 8:03 AM, "Alex Harui" <aharui@adobe.com.invalid> wrote:
>=20
> I agree we have to be concerned about DRY.  Research into optimal =
patterns
> for creating common flavors of beads would be very helpful.  The =
compiler
> might be able to help as well.
>=20
> -Alex
>=20
> On 6/6/17, 6:52 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:
>=20
>> 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.
>>=20
>> 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.
>>=20
>> - Josh
>>=20
>> On Tue, Jun 6, 2017 at 12:02 AM, Justin Mclean =
<justin@classsoftware.com>
>> wrote:
>>=20
>>> Hi,
>>>=20
>>>> Unless something is functionality that you would (virtually) always
>>> need, it=E2=80=99s a separate bead.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>>> PAYG is already well understood
>>>=20
>>> 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.
>>>=20
>>>> All functionality should be implemented as beads when practical. =
Beads
>>> should be as modular as possible with the smallest possible =
functional
>>> set.
>>>=20
>>> 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?
>>>=20
>>> Thanks,
>>> Justin