yes and those i already came across some in wicket
i changed to <?> and suddenly in extentions and/or examples compile errors
all over the place...
then i quickly turn it off again... (for now)
johan
On Thu, May 15, 2008 at 4:31 PM, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
> this is the usecase we are talking about. i get a compile error, which
> sucks.
>
> public class Test
> {
> public static void main(String[] args)
> {
> Foo foo = new FooImpl();
> foo.foo(IntegerComponent.class); // ok
> foo.foo(Component.class); // compile error
> }
>
> public static class Component<T> {}
> public static class IntegerComponent extends Component<Integer> {}
>
> public static interface Foo
> {
> public void foo(Class< ? extends Component< ? >> clazz);
> }
>
> public static class FooImpl implements Foo
> {
> public void foo(Class< ? extends Component< ? >> clazz) {}
> }
> }
>
> -igor
>
> On Wed, May 14, 2008 at 11:56 PM, Sebastiaan van Erk
> <[EMAIL PROTECTED]> wrote:
> > Igor Vaynberg wrote:
> >>
> >> well, apparently johan ran into a situation where component<?> is too
> >> restrictive...
> >
> > As I understand it, Johan ran into a situation where Component<?> causes
> > *warnings* for users who use raw types. Which I've been arguing all along
> > that they SHOULD get: they should use Component<Object> or
> Component<Void>
> > instead of raw types, or live-with/suppress the warning.
> >
> > To make it clear, I made the following test class:
> >
> > public class Test<T> {
> >
> > public void doTest(Test<? extends Test<?>> test) {
> > System.out.println("test");
> > }
> >
> > public static void main(String[] args) {
> > Test<Test<Integer>> test1 = newInstance(); // fine - no
> > warnings.
> > Test<Test> test2 = newInstance(); // not fine, use of raw
> > type, warning
> > Test test3 = newInstance(); // not fine, use of raw type,
> > warning
> >
> > test1.doTest(test1); // fine - no warnings.
> > test1.doTest(test2); // error - generic types don't match,
> > can be "fixed" by line below
> > test1.doTest((Test) test2); // warning - unchecked
> conversion
> > test1.doTest(test3); // warning - unchecked conversion
> > }
> >
> > public static <T> Test<T> newInstance() {
> > return new Test<T>();
> > }
> > }
> >
> > As you can see, there is only one case when you get a compile error when
> > using the <? extends Test<?>> generic type, and that is a case where
> there
> > is on the user side an incorrect generic type: Test<Test>. The user here
> > declares he's using generics, but then inserts a raw type of a known
> generic
> > type - a situation that should not happen.
> >
> > Regards,
> > Sebastiaan
> >
> >> -igor
> >>
> >>
> >> On Wed, May 14, 2008 at 2:37 PM, Sebastiaan van Erk <
> [EMAIL PROTECTED]>
> >> wrote:
> >>>
> >>> Igor Vaynberg wrote:
> >>>>
> >>>> since then the thread has evolved into whether or not we should use <?
> >>>> extends Component> or <? extends Component<?>>
> >>>>
> >>>> -igor
> >>>
> >>> I don't understand how that changes any of my points. The first is
> >>> incorrect
> >>> (from a generics point of view) since you're referencing an
> >>> unparameterized
> >>> generic type.
> >>>
> >>> So the second gives warnings only in code that is not properly
> >>> generified...
> >>>
> >>> Regards,
> >>> Sebastiaan
> >>>
> >>>
> >>>> On Wed, May 14, 2008 at 1:54 PM, Sebastiaan van Erk
> >>>> <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>>
> >>>>> Igor Vaynberg wrote:
> >>>>>
> >>>>>> i do like generics. did i ever say otherwise? the problem here is
> that
> >>>>>> if we scope something as Class<? extends Component> then even though
> >>>>>> you ARE using generics in your code you will still get a warning
> >>>>>> because we did not scope the class as Class<? extends Component<?>>.
> >>>>>>
> >>>>>> on the other hand if we do scope it as Class<? extends Component<?>>
> >>>>>> then you can no longer pass a raw reference when calling the
> function.
> >>>>>
> >>>>> But that's exactly the point isn't it? If you're using generics then
> >>>>> you
> >>>>> shouldn't be using raw Components anymore...
> >>>>>
> >>>>>> so we are screwed if we do and we are screwed if we dont, i expected
> >>>>>> generics to be better.
> >>>>>
> >>>>> Well they definitely could have been better (erasure is terrible if
> you
> >>>>> ask
> >>>>> me), but I don't see what's wrong in this case. It warns you if you
> >>>>> should
> >>>>> be using a parameterized type but you don't.
> >>>>>
> >>>>>>> And especially if you look at the vote result, I think the majority
> >>>>>>> wants
> >>>>>>> the generics...
> >>>>>>
> >>>>>> that vote was before we uncovered this issue. we voted on the idea
> of
> >>>>>> generics, not on the implementation.
> >>>>>
> >>>>> That's true, but I wonder if this issue would change the vote much. I
> >>>>> don't
> >>>>> really understand why it's an issue, because you can use generified
> >>>>> Components always: Component<Object> if you don't want to constrain
> the
> >>>>> model object, and Component<Void> if you don't need a model.
> >>>>>
> >>>>> The question that started the thread was about StringResourceModel
> >>>>> which
> >>>>> was
> >>>>> not yet generified, and in that case, the warning seems to me to be
> >>>>> perfectly ok: it just says StringResourceModel should be generified.
> >>>>> It's
> >>>>> not a release yet, so that some users who use the current snapshot
> run
> >>>>> into
> >>>>> these kind of warnings which cannot be removed seems to be fine to
> >>>>> me...
> >>>>>
> >>>>> Regards,
> >>>>> Sebastiaan
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
