I think it was originally standalone and changed to the current extending interface after feedback on the mailing list.
I'm fine with standalone interfaces and having the implementation implement multiple interfaces. Remko Sent from my iPhone > On Jan 17, 2017, at 6:25, Matt Sicker <boa...@gmail.com> wrote: > > I agree on not extending interfaces. Some of the other context map interfaces > are standalone, and I don't see why TCM2 had to extend anything. > >> On 16 January 2017 at 15:16, Apache <ralph.go...@dslextreme.com> wrote: >> I presume it was named ThreadContextMap3 so there could be a >> ThreadContextMap4 since 3 extends 2 and 2 extends the first one. Frankly, I >> dislike this practice very, very much. Instead, each interface should be >> named as you suggest and NOT extend the prior interface. Instead, the >> implementation should declare that it implements each of these. >> >> Ralph >> >>> On Jan 16, 2017, at 2:02 PM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> Can we come up with a better name before we release this and get stuck with >>> such a terrible interface name? All it adds is a removeAll(Iterable) >>> method, so perhaps something like CleanableThreadContextMap or >>> RemovableThreadContextMap. >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >> > > > > -- > Matt Sicker <boa...@gmail.com>
