On 9/13/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
> Hello Adam,
>
> On 9/13/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > I'm not sure I see the benefit, but I'm not always spot-on
> > when it comes to wildcards in collections...
> >
> > Does the change mean that you're allowed to pass
> > a Map<String, String> to this without casting, whereas
> > before you couldn't?
>
> Yeah, that's the only benefit. More specifically, it allow the following to
> work:
>
> icon.renderIcon(context, rc, Collections.singletonMap("shortDesc", "foo"));Ah, that's a good enough justification for me! > > The common use-cases here all > > have a heterogeneous value type (because of "embedded"), > > so if I'm understanding this correctly, I don't see the benefit > > of this change. > > > > (BTW, I thought that in fact was possible to add elements > > to "? super ...", just not "? extends ...".) > > Exactly, but it would really makes no sense at all to use super in that > signature imho. Oh, absolutely - I just was self-testing my knowledge of generics since you wrote "impossible to add an element to a collection containing a wildcard". I got worried that I didn't understand "? super" as well as I thought I did. :) -- Adam > > > -- Adam > > > > > > On 9/13/07, Simon Lessard < [EMAIL PROTECTED]> wrote: > > > Hello, > > > > > > I would like to do a public API change to Icon's renderIcon method and > its > > > dependencies. Currently the signature is > > > > > > abstract public void renderIcon( > > > FacesContext context, > > > RenderingContext arc, > > > Map<String, Object> attrs > > > ) throws IOException; > > > > > > I would like to change that to the following to make it easier to call > > > because of non covariance of generic collections. > > > > > > abstract public void renderIcon( > > > FacesContext context, > > > RenderingContext arc, > > > Map<String, ? extends Object> attrs > > > ) throws IOException; > > > > > > I don't think it'll break anything as it's a generalization of the > previous > > > signature, meaning all old code should still be able to call the method > > > without any change. The only implication is that renderIcon and its > > > dependencies will no longer be able to alter the map since it's quite > > > impossible to add an element to a collection containing a wildcard. It's > not > > > in the method contract to alter the attribute map though, so it should > not > > > be an issue. However, as it's a public API change, I preferred to ask on > the > > > mailing list in case I oversaw something. > > > > > > > > > Regards, > > > > > > ~ Simon > > > > > > >
