[almighty] almighty-public Digest, Vol 5, Issue 35

Fri Sep 23 13:27:48 UTC 2016

Work item type and work item are generic enough to represent and
understand. As someone mentioned earlier, planner item would imply that the
object only relates to the planning phase.

Labels and flexibility sound good, would just want to make sure that we
create a better end user experience than Google and not create the
usability mistakes that Google has made with all that flexibility : )

-Monica

On Thu, Sep 22, 2016 at 12:00 PM, <almighty-public-request at redhat.com>
wrote:

> Send almighty-public mailing list submissions to
>         almighty-public at redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.redhat.com/mailman/listinfo/almighty-public
> or, via email, send a message with subject or body 'help' to
>         almighty-public-request at redhat.com
>
> You can reach the person managing the list at
>         almighty-public-owner at redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of almighty-public digest..."
>
>
> Today's Topics:
>
>    1. Re: Equaler considered harmful (Andrew Lee Rubinger)
>    2. Terminology: work item -> planner item (Baiju Muthukadan)
>    3. Re: Terminology: work item -> planner item (Andrew Lee Rubinger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 22 Sep 2016 11:35:34 -0400
> From: Andrew Lee Rubinger <alr at redhat.com>
> To: Konrad Kleine <kkleine at redhat.com>
> Cc: ALMighty-public <almighty-public at redhat.com>, Thomas M?der
>         <tmader at redhat.com>
> Subject: Re: [almighty] Equaler considered harmful
> Message-ID:
>         <CABm567H_tRQYbeOhdEn_oS3G95Dfw8r1YhBo2ydDBQdenXSHTw
> @mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Also, a bit curious:
>
> Equality {
>     Equals(left interface{}, right interface{}) bool
> }
>
> What does the implementation of this look like?  Its usage?  Because now to
> achieve your point 4) we've moved the responsibility of determining
> equality from the object in question to some external equality-checker.
> How does the equality-checker know about the various types it has to
> support?
>
> S,
> ALR
>
> On Thu, Sep 22, 2016 at 11:30 AM, Andrew Lee Rubinger <alr at redhat.com>
> wrote:
>
> > Java may have made an odd design design by putting "boolean
> > equals(Object)" in the root Object class as a mechanism to test equality
> by
> > value, but there's also:
> >
> >   https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html
> >
> > This approach handles not just equals but also greater/less than
> > comparisons for types that have ordered values.  You could retrofit it to
> > return an enum type instead of an int for better clarity.
> >
> > Something to consider :)
> >
> > S,
> > ALR
> >
> > On Thu, Sep 22, 2016 at 10:19 AM, Konrad Kleine <kkleine at redhat.com>
> > wrote:
> >
> >> Hi Thomas,
> >>
> >> thanks for not pointing in my direction :)
> >>
> >> I can't wait to see a PR for this.
> >>
> >> Regards,
> >> Konrad
> >>
> >> On Thu, Sep 22, 2016 at 3:32 PM, Thomas M?der <tmader at redhat.com>
> wrote:
> >>
> >>> Hi folks,
> >>>
> >>> some time back, we have introduced the "Equaler" interface. I believe
> >>> we're going down the wrong path with this: Java got this wrong
> initially
> >>> and we still suffer the consequences. Equaler looks like this:
> >>>
> >>> type Equaler interface {
> >>>     Equal(Equaler) bool
> >>> }
> >>>
> >>> There are a couple of drawbacks to this approach:
> >>>
> >>>    1. There can only be a single implementation of Equals for all time.
> >>>    But this too restrictive: for example, I might want to include the
> version
> >>>    field in a struct in the comparison for some cases, in other cases
> I simply
> >>>    don't care. Generally, there can be many equivalence relationships
> for a
> >>>    given set of objects. For all we know, we might consider two
> objects equal
> >>>    if they have the same color.
> >>>    2. You can't compose equality with this implementation
> >>>    In Java, this has given rise to classes like "EqualsBuilder" that
> >>>    allowed to do exactly that.
> >>>    3. We can't implement equality based on interfaces
> >>>    We'd have to reimplement equality for every struct (which is the
> >>>    first parameter).
> >>>    4. You always have to check for null before calling Equals()
> >>>
> >>> So I propose to rewrite the interface to :
> >>>
> >>> Equality {
> >>>
> >>>     Equals(left interface{}, right interface{}) bool
> >>>
> >>> }
> >>>
> >>> I think it would make sense that I prepare a PR to illustrate my
> >>> approach porting the current implementations in the "models" packe. A
> POC
> >>> shouldn't take too long.
> >>>
> >>> thoughts?
> >>>
> >>> /Thomas
> >>>
> >>> _______________________________________________
> >>> almighty-public mailing list
> >>> almighty-public at redhat.com
> >>> https://www.redhat.com/mailman/listinfo/almighty-public
> >>>
> >>>
> >>
> >> _______________________________________________
> >> almighty-public mailing list
> >> almighty-public at redhat.com
> >> https://www.redhat.com/mailman/listinfo/almighty-public
> >>
> >>
> >
> >
> > --
> > Red Hat Developer Programs Architecture
> > @ALRubinger
> >
>
>
>
> --
> Red Hat Developer Programs Architecture
> @ALRubinger
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://www.redhat.com/archives/almighty-public/
> attachments/20160922/b5cadb77/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 22 Sep 2016 21:27:18 +0530
> From: Baiju Muthukadan <bmuthuka at redhat.com>
> To: ALMighty-public <almighty-public at redhat.com>
> Subject: [almighty] Terminology: work item -> planner item
> Message-ID:
>         <CAJi4GASx7kzHDXi0w9sHf3Uw6qZwgiYXWqbD8WG62Ai-mXLV6w at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi All,
>
> Can we change what we are calling today as work item to planner item ?
>
> Regards,
> Baiju M
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://www.redhat.com/archives/almighty-public/
> attachments/20160922/a802b1dd/attachment.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 22 Sep 2016 11:59:51 -0400
> From: Andrew Lee Rubinger <alr at redhat.com>
> To: Baiju Muthukadan <bmuthuka at redhat.com>
> Cc: ALMighty-public <almighty-public at redhat.com>
> Subject: Re: [almighty] Terminology: work item -> planner item
> Message-ID:
>         <CABm567HsNp1rWznzxV5j9jDbDa=JKNwh8mtwqFYzFJ=so9oUjw at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Sep 22, 2016 at 11:57 AM, Baiju Muthukadan <bmuthuka at redhat.com>
> wrote:
>
> > Hi All,
> >
> > Can we change what we are calling today as work item to planner item ?
> >
>
> Nope. :)
>
> Work Items are more generic; they may represent entities not part of the
> Planner, but instead in Build, Code, etc services.
>
> S,
> ALR
>
>
> >
> > Regards,
> > Baiju M
> >
> > _______________________________________________
> > almighty-public mailing list
> > almighty-public at redhat.com
> > https://www.redhat.com/mailman/listinfo/almighty-public
> >
> >
>
>
> --
> Red Hat Developer Programs Architecture
> @ALRubinger
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://www.redhat.com/archives/almighty-public/
> attachments/20160922/8152585a/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
> End of almighty-public Digest, Vol 5, Issue 35
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160923/5f7106e7/attachment.htm>