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

Max Rydahl Andersen manderse at redhat.com
Mon Sep 26 09:27:23 UTC 2016 

On 23 Sep 2016, at 15:27, Monica Granfield wrote:

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

Or that these items would *only* be created by or used by the planner 
which is not the case imo.

> 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 : )

Yes, google really messed up their UX around this across their product 
lines.
i.e. label are folders in gmail but not really, in google drive you have 
folders
but not labels and their folder ui is super-rigid/arcane.

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


> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public


/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160926/ef5081ff/attachment.htm>

More information about the almighty-public mailing list