I agree with Ralph. 

I am working on custom implementations of ThreadContextMap (LOG4J2-1010, 
LOG4J2-1447, LOG4J2-1349) and I'm very glad the interface is small. 

My rule of thumb for API design is YAGNI: don't add until you really need it, 
otherwise it'll get in the way. 

Remko

Sent from my iPhone

> On 2016/08/21, at 4:59, Ralph Goers <[email protected]> wrote:
> 
> 1. Why?  
> 2. Why do you need to implement equals and hashcode? What other map are you 
> going to compare it with?
> 2. Which version? Java 8 added a bunch of new methods.
> 
> I don’t really view the thread context map as a Map. It is really nothing 
> more than a bunch of keys and values that I want to store that are probably 
> not really directly related with each other, much like HTTP session 
> attributes.  When there are cases of wanting to iterate through the whole map 
> we first get a copy of it.
> 
> Ralph
> 
>> On Aug 20, 2016, at 11:01 AM, Gary Gregory <[email protected]> wrote:
>> 
>> Fair enough.
>> 
>> I am wondering if there is a design reason not to implement Map now that we 
>> have the opportunity with the TCM2 interface. I'd take a crack at it.
>> 
>> Gary
>> 
>> 
>>> On Aug 20, 2016 10:39 AM, "Ralph Goers" <[email protected]> wrote:
>>> Because Map has a lot more methods that weren’t needed and I didn’t want to 
>>> implement?
>>> 
>>> Ralph
>>> 
>>>> On Aug 20, 2016, at 10:16 AM, Gary Gregory <[email protected]> wrote:
>>>> 
>>>> Hi All:
>>>> 
>>>> Now that we have ThreadContextMap2:
>>>> 
>>>> Why don't we do ThreadContextMap2 extends Map<String, String>?
>>>> 
>>>> Why did ThreadContextMap initially not extends Map<String, String>?
>>>> 
>>>> Gary
>>>> 
>>>> -- 
>>>> E-Mail: [email protected] | [email protected] 
>>>> Java Persistence with Hibernate, Second Edition
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> Blog: http://garygregory.wordpress.com 
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
> 

Reply via email to