Re: Using generics with some non-generic classes in Wicket

[Sebastiaan van Erk]

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 ComponentObject or 
ComponentVoid instead of raw types, or live-with/suppress the warning.


To make it clear, I made the following test class:

public class TestT {

public void doTest(Test? extends Test? test) {
System.out.println(test);
}

public static void main(String[] args) {
TestTestInteger test1 = newInstance(); // fine - no 
warnings.
TestTest 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 TestT newInstance() {
return new TestT();
}
}

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: TestTest. 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: ComponentObject if you don't want to constrain the
model object, and ComponentVoid 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]



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using generics with some non-generic classes in Wicket

[Peter Ertl]

this one will do:

public X extends Component? void foo(ClassX clazz);

however, the subtle differences between this and igors version are  
really hard to get.




Am 15.05.2008 um 16:31 schrieb Igor Vaynberg:

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 ComponentT {}
   public static class IntegerComponent extends ComponentInteger {}

   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 ComponentObject or  
ComponentVoid

instead of raw types, or live-with/suppress the warning.

To make it clear, I made the following test class:

public class TestT {

  public void doTest(Test? extends Test? test) {
  System.out.println(test);
  }

  public static void main(String[] args) {
  TestTestInteger test1 = newInstance(); // fine - no
warnings.
  TestTest 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 TestT newInstance() {
  return new TestT();
  }
}

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: TestTest. 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: ComponentObject if you don't want to  
constrain the

model object, and ComponentVoid 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 

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

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 ComponentT {}
public static class IntegerComponent extends ComponentInteger {}

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 ComponentObject or ComponentVoid
 instead of raw types, or live-with/suppress the warning.

 To make it clear, I made the following test class:

 public class TestT {

public void doTest(Test? extends Test? test) {
System.out.println(test);
}

public static void main(String[] args) {
TestTestInteger test1 = newInstance(); // fine - no
 warnings.
TestTest 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 TestT newInstance() {
return new TestT();
}
 }

 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: TestTest. 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: ComponentObject if you don't want to constrain the
 model object, and ComponentVoid 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 

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

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 ComponentT {}
public static class IntegerComponent extends ComponentInteger {}

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 ComponentObject or
 ComponentVoid
  instead of raw types, or live-with/suppress the warning.
 
  To make it clear, I made the following test class:
 
  public class TestT {
 
 public void doTest(Test? extends Test? test) {
 System.out.println(test);
 }
 
 public static void main(String[] args) {
 TestTestInteger test1 = newInstance(); // fine - no
  warnings.
 TestTest 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 TestT newInstance() {
 return new TestT();
 }
  }
 
  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: TestTest. 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: ComponentObject if you don't want to constrain
 the
  model object, and ComponentVoid 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 

Re: Using generics with some non-generic classes in Wicket

[Peter Ertl]

taken from SUN's generic tutorial:

http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
end of page 8

 snip :::

interface CollectionE
{
public boolean containsAll(Collection? c);
public boolean addAll(Collection? extends E c);
}
We could have used generic methods here instead:
interface CollectionE
{
public T boolean containsAll(CollectionT c);
public T extends E boolean addAll(CollectionT c);
// hey, type variables can have bounds too!
}
 snip :::

isn't addAll() that the same as

 public void foo(Class ? extends Component ?  clazz);

and

 public X extends Component? void foo(ClassX clazz);

???

seems like this is our first generic bug :-)




Am 15.05.2008 um 16:41 schrieb Peter Ertl:


this one will do:

   public X extends Component? void foo(ClassX clazz);

however, the subtle differences between this and igors version are  
really hard to get.




Am 15.05.2008 um 16:31 schrieb Igor Vaynberg:

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 ComponentT {}
  public static class IntegerComponent extends ComponentInteger {}

  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 ComponentObject or  
ComponentVoid

instead of raw types, or live-with/suppress the warning.

To make it clear, I made the following test class:

public class TestT {

 public void doTest(Test? extends Test? test) {
 System.out.println(test);
 }

 public static void main(String[] args) {
 TestTestInteger test1 = newInstance(); // fine - no
warnings.
 TestTest 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 TestT newInstance() {
 return new TestT();
 }
}

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

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

I dont care, because i cant do any thing with the ? The only thing it
enforces is that it must now be a generic class which is annoying. Not
to mention that in that area eclipse and javac accept different
things

So or we in wicket dont use ? any where and have supress warning
everywhere for that or we do use it and then suddenly it is in my eyes
restricted to much.

On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 Johan Compagner wrote:
  yes thats the reason
 
  you are calling the method add with a generified component but that
  container itself is not generified
 
  i dont like this about generics expecially the onces like this:
 
  add(MarkupContainer? container)
 
  then suddenly a none generified component cant be added...
  thats really stupid ? should mean anything.. including none generics

 No, that's not correct. For example, List? is much more restrictive
 than a raw List (which is a ListObject). To a raw list you can add an
 instance of any type whatever, i.e., list.add(new Object()). But in
 List? the ? is a wildcard which says it could be any type there, i.e.,
 it could be a ListInteger. But you can't add a new Object() to a
 ListInteger!

 Thus MarkupContainer? means MarkupContainer parameterized by some
 unknown type, and *not* MarkupContainer parameterized by Object, which
 is what the raw type means.

 Regards,
 Sebastiaan

  johan
 
 
  On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
  wrote:
 
  I have one idea,
 
  the reason of the warnigs is, that parent of AjaxPagingNavigator is
  PagingNavigator,
  which has parent Panel --- that is not parameterized.
 
  The same problem is with LoopItem, which extends the
  WebMarkupContainer --- that is not parameterized.
 
  ? could this be the reason ?
 
 
 
 
 
 
  Stefan Simik wrote:
  Mhmm, it is meaningful ;) I will know in future, thx
 
  One of the last occuring warning is, when working with
  MarkupContainer#add(...)  or  #addOrReplace(...)  method.
 
  Example:  I have a simple AjaxPagingNavigator, to which I add a simple
  ListView
  ---
  ListViewInteger menu = new ListViewInteger(id, numbers){
  //populate metods
  }
  add(menu);//warning here
 
  The warning says:
  Type safety: The method add(Component...) belongs to the raw type
  MarkupContainer.
  References to generic type MarkupContainerT should be parameterized
 
  I cannot find out, what's the warning reason, because ListView self is
  parameterized.
 
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  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]

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

I dont think that user gets a warning if a param is of raw type. But
we have a warning there.
The problem is that for example MarkupContainer.add(Component) or
IVisitor.visit(Component) i dont care what component is put in
generified or not.
In add it really doesnt matter because we dont do anything with it.
With visitor it is different because the user could use it inside the
method. But it should be useable without warnings for generified and
none generfied components..


On 5/14/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
 if we have a signature that accepts a raw type, will that also cause a
 warning in user's code?

 also having those suppress annotations practically _everywhere_ will be
 annoying

 -igor


 On Tue, May 13, 2008 at 11:56 PM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  I dont care, because i cant do any thing with the ? The only thing it
   enforces is that it must now be a generic class which is annoying. Not
   to mention that in that area eclipse and javac accept different
   things
 
   So or we in wicket dont use ? any where and have supress warning
   everywhere for that or we do use it and then suddenly it is in my eyes
   restricted to much.
 
 
 
   On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
Johan Compagner wrote:
 yes thats the reason

 you are calling the method add with a generified component but that
 container itself is not generified

 i dont like this about generics expecially the onces like this:

 add(MarkupContainer? container)

 then suddenly a none generified component cant be added...
 thats really stupid ? should mean anything.. including none
 generics
   
No, that's not correct. For example, List? is much more restrictive
than a raw List (which is a ListObject). To a raw list you can add an
instance of any type whatever, i.e., list.add(new Object()). But in
List? the ? is a wildcard which says it could be any type there,
 i.e.,
it could be a ListInteger. But you can't add a new Object() to a
ListInteger!
   
Thus MarkupContainer? means MarkupContainer parameterized by some
unknown type, and *not* MarkupContainer parameterized by Object, which
is what the raw type means.
   
Regards,
Sebastiaan
   
 johan


 On Tue, May 13, 2008 at 5:55 PM, Stefan Simik
 [EMAIL PROTECTED]
 wrote:

 I have one idea,

 the reason of the warnigs is, that parent of AjaxPagingNavigator is
 PagingNavigator,
 which has parent Panel --- that is not parameterized.

 The same problem is with LoopItem, which extends the
 WebMarkupContainer --- that is not parameterized.

 ? could this be the reason ?






 Stefan Simik wrote:
 Mhmm, it is meaningful ;) I will know in future, thx

 One of the last occuring warning is, when working with
 MarkupContainer#add(...)  or  #addOrReplace(...)  method.

 Example:  I have a simple AjaxPagingNavigator, to which I add a
 simple
 ListView

 ---
 ListViewInteger menu = new ListViewInteger(id, numbers){
 //populate metods
 }
 add(menu);//warning here

 The warning says:
 Type safety: The method add(Component...) belongs to the raw type
 MarkupContainer.
 References to generic type MarkupContainerT should be
 parameterized

 I cannot find out, what's the warning reason, because ListView self
 is
 parameterized.


 --
 View this message in context:

   
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
 Sent from the Wicket - User mailing list archive at Nabble.com.



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



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Sebastiaan van Erk]

My post kind of missed the point, I shouldn't post when I'm already half 
asleep. :-)


Obviously MarkupContainerObject satisfies the MarkupContainer? in a 
method argument, so it accepts the raw type. However, it generates a 
warning because the method says it's generified, so you should be using 
the generic type.


Johan Compagner wrote:

I dont care, because i cant do any thing with the ? The only thing it
enforces is that it must now be a generic class which is annoying. Not
to mention that in that area eclipse and javac accept different
things


The reason it warns you to use generics when generics are wanted is 
because Sun wants to be able to make it *required* (in a future release) 
to use generics where generics are wanted; at least, so I read... I 
think in the real world they wouldn't dare to do this because it would 
piss off so many users and break so much stuff. :-)


But the idea is that if something is generified you should be using a 
type parameter, and using a raw type is *purely* for backwards 
compatibility with legacy code.


Regards,
Sebastiaan


So or we in wicket dont use ? any where and have supress warning
everywhere for that or we do use it and then suddenly it is in my eyes
restricted to much.


I don't understand


On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Johan Compagner wrote:

yes thats the reason

you are calling the method add with a generified component but that
container itself is not generified

i dont like this about generics expecially the onces like this:

add(MarkupContainer? container)

then suddenly a none generified component cant be added...
thats really stupid ? should mean anything.. including none generics

No, that's not correct. For example, List? is much more restrictive
than a raw List (which is a ListObject). To a raw list you can add an
instance of any type whatever, i.e., list.add(new Object()). But in
List? the ? is a wildcard which says it could be any type there, i.e.,
it could be a ListInteger. But you can't add a new Object() to a
ListInteger!

Thus MarkupContainer? means MarkupContainer parameterized by some
unknown type, and *not* MarkupContainer parameterized by Object, which
is what the raw type means.

Regards,
Sebastiaan


johan


On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
wrote:


I have one idea,

the reason of the warnigs is, that parent of AjaxPagingNavigator is
PagingNavigator,
which has parent Panel --- that is not parameterized.

The same problem is with LoopItem, which extends the
WebMarkupContainer --- that is not parameterized.

? could this be the reason ?






Stefan Simik wrote:

Mhmm, it is meaningful ;) I will know in future, thx

One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.

Example:  I have a simple AjaxPagingNavigator, to which I add a simple
ListView
---
ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here

The warning says:
Type safety: The method add(Component...) belongs to the raw type
MarkupContainer.
References to generic type MarkupContainerT should be parameterized

I cannot find out, what's the warning reason, because ListView self is
parameterized.



--
View this message in context:


http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html

Sent from the Wicket - User mailing list archive at Nabble.com.


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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

The problem is that wicket needs an annotation

genericsOptional

so that all the warnings about raw types are gone.

A component only has to be generic if you use the IModel constructor or call
getModel(), getModelObject() methods..
for the rest it is not really needed

johan

On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk [EMAIL PROTECTED]
wrote:

 My post kind of missed the point, I shouldn't post when I'm already half
 asleep. :-)

 Obviously MarkupContainerObject satisfies the MarkupContainer? in a
 method argument, so it accepts the raw type. However, it generates a warning
 because the method says it's generified, so you should be using the generic
 type.

 Johan Compagner wrote:

  I dont care, because i cant do any thing with the ? The only thing it
  enforces is that it must now be a generic class which is annoying. Not
  to mention that in that area eclipse and javac accept different
  things
 

 The reason it warns you to use generics when generics are wanted is
 because Sun wants to be able to make it *required* (in a future release) to
 use generics where generics are wanted; at least, so I read... I think in
 the real world they wouldn't dare to do this because it would piss off so
 many users and break so much stuff. :-)

 But the idea is that if something is generified you should be using a type
 parameter, and using a raw type is *purely* for backwards compatibility with
 legacy code.

 Regards,
 Sebastiaan

  So or we in wicket dont use ? any where and have supress warning
  everywhere for that or we do use it and then suddenly it is in my eyes
  restricted to much.
 

 I don't understand


  On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 
   Johan Compagner wrote:
  
yes thats the reason
   
you are calling the method add with a generified component but that
container itself is not generified
   
i dont like this about generics expecially the onces like this:
   
add(MarkupContainer? container)
   
then suddenly a none generified component cant be added...
thats really stupid ? should mean anything.. including none
generics
   
   No, that's not correct. For example, List? is much more restrictive
   than a raw List (which is a ListObject). To a raw list you can add
   an
   instance of any type whatever, i.e., list.add(new Object()). But in
   List? the ? is a wildcard which says it could be any type there,
   i.e.,
   it could be a ListInteger. But you can't add a new Object() to a
   ListInteger!
  
   Thus MarkupContainer? means MarkupContainer parameterized by some
   unknown type, and *not* MarkupContainer parameterized by Object,
   which
   is what the raw type means.
  
   Regards,
   Sebastiaan
  
johan
   
   
On Tue, May 13, 2008 at 5:55 PM, Stefan Simik 
[EMAIL PROTECTED]
wrote:
   
 I have one idea,

 the reason of the warnigs is, that parent of AjaxPagingNavigator
 is
 PagingNavigator,
 which has parent Panel --- that is not parameterized.

 The same problem is with LoopItem, which extends the
 WebMarkupContainer --- that is not parameterized.

 ? could this be the reason ?






 Stefan Simik wrote:

  Mhmm, it is meaningful ;) I will know in future, thx
 
  One of the last occuring warning is, when working with
  MarkupContainer#add(...)  or  #addOrReplace(...)  method.
 
  Example:  I have a simple AjaxPagingNavigator, to which I add a
  simple
  ListView
 
  ---
  ListViewInteger menu = new ListViewInteger(id, numbers){
 //populate metods
  }
  add(menu);//warning here
 
  The warning says:
  Type safety: The method add(Component...) belongs to the raw
  type
  MarkupContainer.
  References to generic type MarkupContainerT should be
  parameterized
 
  I cannot find out, what's the warning reason, because ListView
  self is
  parameterized.
 
 
   --
 View this message in context:


   http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
  
Sent from the Wicket - User mailing list archive at Nabble.com.



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

Re: Using generics with some non-generic classes in Wicket

[Doug Donohoe]

.
 
 
   --
 View this message in context:


  
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
  
Sent from the Wicket - User mailing list archive at Nabble.com.




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

-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17229755.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Using generics with some non-generic classes in Wicket

[Hoover, William]

imho, that seems like that adds a lot of unnecessary code. One of the
nice things about Wicket is that it keeps the bloat to a minimum.

-Original Message-
From: Doug Donohoe [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 14, 2008 8:21 AM
To: users@wicket.apache.org
Subject: Re: Using generics with some non-generic classes in Wicket


Somewhat related to this thread, when I moved to generics win Wicket
1.4,  I created some utility classes such as:

public class VoidContainer extends WebMarkupContainerlt;Void public
class VoidPanel extends Panellt;Void public class StringLabel extends
Labellt;String

public class IntegerModel extends Modellt;Integer public class
StringModel extends Modellt;String public class DateModel extends
Modellt;Date public class DoubleModel extends Modellt;Double

And so on.  This made my wicket code cleaner and easier to use.  I think
the Wicket 1.4 generics implementation is headed in the right direction.
It was a pain at first because I had to parameterize everything, but
creating convenience classes like this made it easier.

I'm thinking about creating a patch with a suite of these types of
classes because I think users will want something like this.

-Doug


Johan Compagner wrote:
 
 The problem is that wicket needs an annotation
 
 genericsOptional
 
 so that all the warnings about raw types are gone.
 
 A component only has to be generic if you use the IModel constructor 
 or call getModel(), getModelObject() methods..
 for the rest it is not really needed
 
 johan
 
 On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk 
 [EMAIL PROTECTED]
 wrote:
 
 My post kind of missed the point, I shouldn't post when I'm already 
 half asleep. :-)

 Obviously MarkupContainer satisfies the MarkupContainer? in a 
 method argument, so it accepts the raw type. However, it generates a 
 warning because the method says it's generified, so you should be 
 using the generic type.

 Johan Compagner wrote:

  I dont care, because i cant do any thing with the ? The only thing 
  it enforces is that it must now be a generic class which is 
  annoying. Not to mention that in that area eclipse and javac accept

  different things
 

 The reason it warns you to use generics when generics are wanted is 
 because Sun wants to be able to make it *required* (in a future 
 release) to use generics where generics are wanted; at least, so I 
 read... I think in the real world they wouldn't dare to do this 
 because it would piss off so many users and break so much stuff. :-)

 But the idea is that if something is generified you should be using a

 type parameter, and using a raw type is *purely* for backwards 
 compatibility with legacy code.

 Regards,
 Sebastiaan

  So or we in wicket dont use ? any where and have supress warning
  everywhere for that or we do use it and then suddenly it is in my 
  eyes restricted to much.
 

 I don't understand


  On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 
   Johan Compagner wrote:
  
yes thats the reason
   
you are calling the method add with a generified component but 
that container itself is not generified
   
i dont like this about generics expecially the onces like this:
   
add(MarkupContainer? container)
   
then suddenly a none generified component cant be added...
thats really stupid ? should mean anything.. including none 
generics
   
   No, that's not correct. For example, List? is much more 
   restrictive than a raw List (which is a List). To a raw list you 
   can add an instance of any type whatever, i.e., list.add(new 
   Object()). But in List? the ? is a wildcard which says it could

   be any type there, i.e., it could be a ListInteger. But you 
   can't add a new Object() to a ListInteger!
  
   Thus MarkupContainer? means MarkupContainer parameterized by 
   some unknown type, and *not* MarkupContainer parameterized by 
   Object, which is what the raw type means.
  
   Regards,
   Sebastiaan
  
johan
   
   
On Tue, May 13, 2008 at 5:55 PM, Stefan Simik  
[EMAIL PROTECTED]
wrote:
   
 I have one idea,

 the reason of the warnigs is, that parent of 
 AjaxPagingNavigator is PagingNavigator, which has parent 
 Panel --- that is not parameterized.

 The same problem is with LoopItem, which extends the 
 WebMarkupContainer --- that is not parameterized.

 ? could this be the reason ?






 Stefan Simik wrote:

  Mhmm, it is meaningful ;) I will know in future, thx
 
  One of the last occuring warning is, when working with
  MarkupContainer#add(...)  or  #addOrReplace(...)  method.
 
  Example:  I have a simple AjaxPagingNavigator, to which I 
  add a simple ListView
 
 
 -
 --
  ListViewInteger menu = new ListViewInteger(id,
numbers){
 //populate metods
  }
  add(menu

Re: Using generics with some non-generic classes in Wicket

[Martijn Dashorst]

 AjaxPagingNavigator, to which I add a
simple
ListView
   
   
   ---
ListViewInteger menu = new ListViewInteger(id, numbers){
   //populate metods
}
add(menu);//warning here
   
The warning says:
Type safety: The method add(Component...) belongs to the raw
type
MarkupContainer.
References to generic type MarkupContainerT should be
parameterized
   
I cannot find out, what's the warning reason, because ListView
self is
parameterized.
   
   
 --
   View this message in context:
  
  

   
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html

  Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
  
  
   -
   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]
   
   
  
  


 --
  View this message in context: 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17229755.html

 Sent from the Wicket - User mailing list archive at Nabble.com.


  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]




-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Using generics with some non-generic classes in Wicket

[Doug Donohoe]

Let me outline what I believe the benefits are.  For example:

add(new LabelString(tournamentName, tournament.getName()));
add(new LabelString(hostName, game.getHostPlayer()));
row.add(new AttributeModifier(class, true, new
ModelString(row.getIndex() % 2 == 0 ? odd : even)));

add(new StringLabel(tournamentName, tournament.getName()));
add(new StringLabel(hostName, game.getHostPlayer()));
row.add(new AttributeModifier(class, true, new StringModel(row.getIndex()
% 2 == 0 ? odd : even)));

Sure, it seems like a small difference and a saving of two characters, but
here is what I believe are the benefits of doing this:

1) I can more easily use the features of my IDE such as auto-completion

2) Find Usages is more accurate (at least in IntelliJ, where I'm not aware
of a find-usages that scopes to a particular generic type)

3) Let's face it, Generics clutters up your code and makes it harder to
read.  This simplifies things a bit.

In answer to Martijn's assumption (in a separate post) that I was going to
iterate over all java types and all wicket types:  that is an incorrect
assumption.  Obviously, I would want to pick the most common use cases and
seek feedback from the community.  Let us not dismiss it outright.  I
believe this is a valid topic of conversation.  Generics are new to Wicket
and still unused by many Java APIs and likely new to many programmers.  I
can tell you that using classes such as this made it much quicker and easier
to remove all the warnings that showed up in my code when I migrated to 1.4. 
It seems easier to replace common usage from before (new Label(...)) with 
new StringLabel(...)  rather than new LabelString (even typing that now
was more difficult).  In any case, there may be some complaining about the
extensive use of Generics in 1.4 once it is released.  This may make it
easier to transition.  Maybe not.  At least let's be open to discussing it.

Finally, in answer to the point about negating the point of generics, I
respectfully disagree.  One major point of generics is to avoid code
duplication of boilerplate code.   It it weren't for the need to create
constructors, there wouldn't be any duplicated code.  I agree that it is a
fine balance to strike, but there are competing needs of readability and
maintainability.

-Doug


Hoover, William wrote:
 
 imho, that seems like that adds a lot of unnecessary code. One of the
 nice things about Wicket is that it keeps the bloat to a minimum.
 
 -Original Message-
 From: Doug Donohoe [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, May 14, 2008 8:21 AM
 To: users@wicket.apache.org
 Subject: Re: Using generics with some non-generic classes in Wicket
 
 
 Somewhat related to this thread, when I moved to generics win Wicket
 1.4,  I created some utility classes such as:
 
 public class VoidContainer extends WebMarkupContainerlt;Void public
 class VoidPanel extends Panellt;Void public class StringLabel extends
 Labellt;String
 
 public class IntegerModel extends Modellt;Integer public class
 StringModel extends Modellt;String public class DateModel extends
 Modellt;Date public class DoubleModel extends Modellt;Double
 
 And so on.  This made my wicket code cleaner and easier to use.  I think
 the Wicket 1.4 generics implementation is headed in the right direction.
 It was a pain at first because I had to parameterize everything, but
 creating convenience classes like this made it easier.
 
 I'm thinking about creating a patch with a suite of these types of
 classes because I think users will want something like this.
 
 -Doug
 
 
 Johan Compagner wrote:
 
 The problem is that wicket needs an annotation
 
 genericsOptional
 
 so that all the warnings about raw types are gone.
 
 A component only has to be generic if you use the IModel constructor 
 or call getModel(), getModelObject() methods..
 for the rest it is not really needed
 
 johan
 
 On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk 
 [EMAIL PROTECTED]
 wrote:
 
 My post kind of missed the point, I shouldn't post when I'm already 
 half asleep. :-)

 Obviously MarkupContainer satisfies the MarkupContainer? in a 
 method argument, so it accepts the raw type. However, it generates a 
 warning because the method says it's generified, so you should be 
 using the generic type.

 Johan Compagner wrote:

  I dont care, because i cant do any thing with the ? The only thing 
  it enforces is that it must now be a generic class which is 
  annoying. Not to mention that in that area eclipse and javac accept
 
  different things
 

 The reason it warns you to use generics when generics are wanted is 
 because Sun wants to be able to make it *required* (in a future 
 release) to use generics where generics are wanted; at least, so I 
 read... I think in the real world they wouldn't dare to do this 
 because it would piss off so many users and break so much stuff. :-)

 But the idea is that if something is generified you should be using a
 
 type parameter, and using a raw type

Re: Using generics with some non-generic classes in Wicket

[Peter Ertl]

 StringModel looks ambigious to me, will it extend

- LoadableDetachableModel
- IModel
- Model
- AbstractReadOnlyModel
- 

???




Am 14.05.2008 um 15:47 schrieb Doug Donohoe:



Let me outline what I believe the benefits are.  For example:

add(new LabelString(tournamentName, tournament.getName()));
add(new LabelString(hostName, game.getHostPlayer()));
row.add(new AttributeModifier(class, true, new
ModelString(row.getIndex() % 2 == 0 ? odd : even)));

add(new StringLabel(tournamentName, tournament.getName()));
add(new StringLabel(hostName, game.getHostPlayer()));
row.add(new AttributeModifier(class, true, new  
StringModel(row.getIndex()

% 2 == 0 ? odd : even)));

Sure, it seems like a small difference and a saving of two  
characters, but

here is what I believe are the benefits of doing this:

1) I can more easily use the features of my IDE such as auto- 
completion


2) Find Usages is more accurate (at least in IntelliJ, where I'm not  
aware

of a find-usages that scopes to a particular generic type)

3) Let's face it, Generics clutters up your code and makes it harder  
to

read.  This simplifies things a bit.

In answer to Martijn's assumption (in a separate post) that I was  
going to
iterate over all java types and all wicket types:  that is an  
incorrect
assumption.  Obviously, I would want to pick the most common use  
cases and

seek feedback from the community.  Let us not dismiss it outright.  I
believe this is a valid topic of conversation.  Generics are new to  
Wicket
and still unused by many Java APIs and likely new to many  
programmers.  I
can tell you that using classes such as this made it much quicker  
and easier
to remove all the warnings that showed up in my code when I migrated  
to 1.4.
It seems easier to replace common usage from before (new Label(...))  
with
new StringLabel(...)  rather than new LabelString (even typing  
that now
was more difficult).  In any case, there may be some complaining  
about the
extensive use of Generics in 1.4 once it is released.  This may make  
it
easier to transition.  Maybe not.  At least let's be open to  
discussing it.


Finally, in answer to the point about negating the point of  
generics, I

respectfully disagree.  One major point of generics is to avoid code
duplication of boilerplate code.   It it weren't for the need to  
create
constructors, there wouldn't be any duplicated code.  I agree that  
it is a
fine balance to strike, but there are competing needs of readability  
and

maintainability.

-Doug


Hoover, William wrote:


imho, that seems like that adds a lot of unnecessary code. One of the
nice things about Wicket is that it keeps the bloat to a minimum.

-Original Message-
From: Doug Donohoe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 14, 2008 8:21 AM
To: users@wicket.apache.org
Subject: Re: Using generics with some non-generic classes in Wicket


Somewhat related to this thread, when I moved to generics win Wicket
1.4,  I created some utility classes such as:

public class VoidContainer extends WebMarkupContainerlt;Void public
class VoidPanel extends Panellt;Void public class StringLabel  
extends

Labellt;String

public class IntegerModel extends Modellt;Integer public class
StringModel extends Modellt;String public class DateModel extends
Modellt;Date public class DoubleModel extends Modellt;Double

And so on.  This made my wicket code cleaner and easier to use.  I  
think
the Wicket 1.4 generics implementation is headed in the right  
direction.

It was a pain at first because I had to parameterize everything, but
creating convenience classes like this made it easier.

I'm thinking about creating a patch with a suite of these types of
classes because I think users will want something like this.

-Doug


Johan Compagner wrote:


The problem is that wicket needs an annotation

genericsOptional

so that all the warnings about raw types are gone.

A component only has to be generic if you use the IModel constructor
or call getModel(), getModelObject() methods..
for the rest it is not really needed

johan

On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk
[EMAIL PROTECTED]
wrote:


My post kind of missed the point, I shouldn't post when I'm already
half asleep. :-)

Obviously MarkupContainer satisfies the MarkupContainer? in a
method argument, so it accepts the raw type. However, it  
generates a

warning because the method says it's generified, so you should be
using the generic type.

Johan Compagner wrote:


I dont care, because i cant do any thing with the ? The only thing
it enforces is that it must now be a generic class which is
annoying. Not to mention that in that area eclipse and javac  
accept



different things



The reason it warns you to use generics when generics are wanted is
because Sun wants to be able to make it *required* (in a future
release) to use generics where generics are wanted; at least, so I
read... I think in the real world they wouldn't dare to do this
because it would

Re: Using generics with some non-generic classes in Wicket

[Doug Donohoe]

From my original post on this topic:

public class StringModel extends ModelString 

-Doug


Peter Ertl wrote:
 
   StringModel looks ambigious to me, will it extend
 
 - LoadableDetachableModel
 - IModel
 - Model
 - AbstractReadOnlyModel
 - 
 
 ???
 
 
 
 
 Am 14.05.2008 um 15:47 schrieb Doug Donohoe:
 

 Let me outline what I believe the benefits are.  For example:

 add(new LabelString(tournamentName, tournament.getName()));
 add(new LabelString(hostName, game.getHostPlayer()));
 row.add(new AttributeModifier(class, true, new
 ModelString(row.getIndex() % 2 == 0 ? odd : even)));

 add(new StringLabel(tournamentName, tournament.getName()));
 add(new StringLabel(hostName, game.getHostPlayer()));
 row.add(new AttributeModifier(class, true, new  
 StringModel(row.getIndex()
 % 2 == 0 ? odd : even)));

 Sure, it seems like a small difference and a saving of two  
 characters, but
 here is what I believe are the benefits of doing this:

 1) I can more easily use the features of my IDE such as auto- 
 completion

 2) Find Usages is more accurate (at least in IntelliJ, where I'm not  
 aware
 of a find-usages that scopes to a particular generic type)

 3) Let's face it, Generics clutters up your code and makes it harder  
 to
 read.  This simplifies things a bit.

 In answer to Martijn's assumption (in a separate post) that I was  
 going to
 iterate over all java types and all wicket types:  that is an  
 incorrect
 assumption.  Obviously, I would want to pick the most common use  
 cases and
 seek feedback from the community.  Let us not dismiss it outright.  I
 believe this is a valid topic of conversation.  Generics are new to  
 Wicket
 and still unused by many Java APIs and likely new to many  
 programmers.  I
 can tell you that using classes such as this made it much quicker  
 and easier
 to remove all the warnings that showed up in my code when I migrated  
 to 1.4.
 It seems easier to replace common usage from before (new Label(...))  
 with
 new StringLabel(...)  rather than new LabelString (even typing  
 that now
 was more difficult).  In any case, there may be some complaining  
 about the
 extensive use of Generics in 1.4 once it is released.  This may make  
 it
 easier to transition.  Maybe not.  At least let's be open to  
 discussing it.

 Finally, in answer to the point about negating the point of  
 generics, I
 respectfully disagree.  One major point of generics is to avoid code
 duplication of boilerplate code.   It it weren't for the need to  
 create
 constructors, there wouldn't be any duplicated code.  I agree that  
 it is a
 fine balance to strike, but there are competing needs of readability  
 and
 maintainability.

 -Doug


 Hoover, William wrote:

 imho, that seems like that adds a lot of unnecessary code. One of the
 nice things about Wicket is that it keeps the bloat to a minimum.

 -Original Message-
 From: Doug Donohoe [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, May 14, 2008 8:21 AM
 To: users@wicket.apache.org
 Subject: Re: Using generics with some non-generic classes in Wicket


 Somewhat related to this thread, when I moved to generics win Wicket
 1.4,  I created some utility classes such as:

 public class VoidContainer extends WebMarkupContainerlt;Void public
 class VoidPanel extends Panellt;Void public class StringLabel  
 extends
 Labellt;String

 public class IntegerModel extends Modellt;Integer public class
 StringModel extends Modellt;String public class DateModel extends
 Modellt;Date public class DoubleModel extends Modellt;Double

 And so on.  This made my wicket code cleaner and easier to use.  I  
 think
 the Wicket 1.4 generics implementation is headed in the right  
 direction.
 It was a pain at first because I had to parameterize everything, but
 creating convenience classes like this made it easier.

 I'm thinking about creating a patch with a suite of these types of
 classes because I think users will want something like this.

 -Doug


 Johan Compagner wrote:

 The problem is that wicket needs an annotation

 genericsOptional

 so that all the warnings about raw types are gone.

 A component only has to be generic if you use the IModel constructor
 or call getModel(), getModelObject() methods..
 for the rest it is not really needed

 johan

 On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk
 [EMAIL PROTECTED]
 wrote:

 My post kind of missed the point, I shouldn't post when I'm already
 half asleep. :-)

 Obviously MarkupContainer satisfies the MarkupContainer? in a
 method argument, so it accepts the raw type. However, it  
 generates a
 warning because the method says it's generified, so you should be
 using the generic type.

 Johan Compagner wrote:

 I dont care, because i cant do any thing with the ? The only thing
 it enforces is that it must now be a generic class which is
 annoying. Not to mention that in that area eclipse and javac  
 accept

 different things


 The reason it warns you to use generics when generics

Re: Using generics with some non-generic classes in Wicket

[Stefan Simik]

Great, it work without warnings now ;)

Joham, could you please change the following class too ?

file: Loop.java
line:53
from:   LoopItem extends WebMarkupContainer
to:  LoopItem extends WebMarkupContainerInteger

thx ;)
Stefan




Johan Compagner wrote:
 
 i already did the commit just yet..
 
 i did make them all   because i think people generally dont want to
 generify them anyway (use the model object)
 
 
 
 On Tue, May 13, 2008 at 9:48 PM, Stefan Simik [EMAIL PROTECTED]
 wrote:
 

 please, and will be these classes later generified ?
 Or should I make a RFE, or can I help anyway-for example attach a patch ?

 I love your work and Wicket, so I do my best, to make it better ;)

 Stefan Simik






 Johan Compagner wrote:
 
  yes thats the reason
 
  you are calling the method add with a generified component but that
  container itself is not generified
 
  i dont like this about generics expecially the onces like this:
 
  add(MarkupContainer? container)
 
  then suddenly a none generified component cant be added...
  thats really stupid ? should mean anything.. including none generics
 
  johan
 
 
  On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
  wrote:
 
 
  I have one idea,
 
  the reason of the warnigs is, that parent of AjaxPagingNavigator is
  PagingNavigator,
  which has parent Panel --- that is not parameterized.
 
  The same problem is with LoopItem, which extends the
  WebMarkupContainer --- that is not parameterized.
 
  ? could this be the reason ?
 
 
 
 
 
 
  Stefan Simik wrote:
  
   Mhmm, it is meaningful ;) I will know in future, thx
  
   One of the last occuring warning is, when working with
   MarkupContainer#add(...)  or  #addOrReplace(...)  method.
  
   Example:  I have a simple AjaxPagingNavigator, to which I add a
 simple
   ListView
  
 ---
   ListViewInteger menu = new ListViewInteger(id, numbers){
   //populate metods
   }
   add(menu);//warning here
  
   The warning says:
   Type safety: The method add(Component...) belongs to the raw type
   MarkupContainer.
   References to generic type MarkupContainerT should be
 parameterized
  
   I cannot find out, what's the warning reason, because ListView self
 is
   parameterized.
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216869.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 

-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17233011.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

hmm i will make it Void
because the LoopItem doesnt really have a model with an Integer in the
model..
it has an primitive int itself stored in it self.

johan


On Wed, May 14, 2008 at 4:52 PM, Stefan Simik [EMAIL PROTECTED]
wrote:


 Great, it work without warnings now ;)

 Joham, could you please change the following class too ?

 file: Loop.java
 line:53
 from:   LoopItem extends WebMarkupContainer
 to:  LoopItem extends WebMarkupContainerInteger

 thx ;)
 Stefan




 Johan Compagner wrote:
 
  i already did the commit just yet..
 
  i did make them all   because i think people generally dont want to
  generify them anyway (use the model object)
 
 
 
  On Tue, May 13, 2008 at 9:48 PM, Stefan Simik [EMAIL PROTECTED]
  wrote:
 
 
  please, and will be these classes later generified ?
  Or should I make a RFE, or can I help anyway-for example attach a patch
 ?
 
  I love your work and Wicket, so I do my best, to make it better ;)
 
  Stefan Simik
 
 
 
 
 
 
  Johan Compagner wrote:
  
   yes thats the reason
  
   you are calling the method add with a generified component but that
   container itself is not generified
  
   i dont like this about generics expecially the onces like this:
  
   add(MarkupContainer? container)
  
   then suddenly a none generified component cant be added...
   thats really stupid ? should mean anything.. including none generics
  
   johan
  
  
   On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
 
   wrote:
  
  
   I have one idea,
  
   the reason of the warnigs is, that parent of AjaxPagingNavigator is
   PagingNavigator,
   which has parent Panel --- that is not parameterized.
  
   The same problem is with LoopItem, which extends the
   WebMarkupContainer --- that is not parameterized.
  
   ? could this be the reason ?
  
  
  
  
  
  
   Stefan Simik wrote:
   
Mhmm, it is meaningful ;) I will know in future, thx
   
One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.
   
Example:  I have a simple AjaxPagingNavigator, to which I add a
  simple
ListView
   
  ---
ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here
   
The warning says:
Type safety: The method add(Component...) belongs to the raw type
MarkupContainer.
References to generic type MarkupContainerT should be
  parameterized
   
I cannot find out, what's the warning reason, because ListView self
  is
parameterized.
   
   
  
   --
   View this message in context:
  
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216869.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17233011.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

and that is the whole problem
who needs the Model itself as a string?
many are dynamic with getObject() impl.
then you shouldnt really do Model but IModel directly

johan


On Wed, May 14, 2008 at 4:29 PM, Doug Donohoe [EMAIL PROTECTED] wrote:


 From my original post on this topic:

 public class StringModel extends ModelString

 -Doug


 Peter Ertl wrote:
 
StringModel looks ambigious to me, will it extend
 
  - LoadableDetachableModel
  - IModel
  - Model
  - AbstractReadOnlyModel
  - 
 
  ???
 
 
 
 
  Am 14.05.2008 um 15:47 schrieb Doug Donohoe:
 
 
  Let me outline what I believe the benefits are.  For example:
 
  add(new LabelString(tournamentName, tournament.getName()));
  add(new LabelString(hostName, game.getHostPlayer()));
  row.add(new AttributeModifier(class, true, new
  ModelString(row.getIndex() % 2 == 0 ? odd : even)));
 
  add(new StringLabel(tournamentName, tournament.getName()));
  add(new StringLabel(hostName, game.getHostPlayer()));
  row.add(new AttributeModifier(class, true, new
  StringModel(row.getIndex()
  % 2 == 0 ? odd : even)));
 
  Sure, it seems like a small difference and a saving of two
  characters, but
  here is what I believe are the benefits of doing this:
 
  1) I can more easily use the features of my IDE such as auto-
  completion
 
  2) Find Usages is more accurate (at least in IntelliJ, where I'm not
  aware
  of a find-usages that scopes to a particular generic type)
 
  3) Let's face it, Generics clutters up your code and makes it harder
  to
  read.  This simplifies things a bit.
 
  In answer to Martijn's assumption (in a separate post) that I was
  going to
  iterate over all java types and all wicket types:  that is an
  incorrect
  assumption.  Obviously, I would want to pick the most common use
  cases and
  seek feedback from the community.  Let us not dismiss it outright.  I
  believe this is a valid topic of conversation.  Generics are new to
  Wicket
  and still unused by many Java APIs and likely new to many
  programmers.  I
  can tell you that using classes such as this made it much quicker
  and easier
  to remove all the warnings that showed up in my code when I migrated
  to 1.4.
  It seems easier to replace common usage from before (new Label(...))
  with
  new StringLabel(...)  rather than new LabelString (even typing
  that now
  was more difficult).  In any case, there may be some complaining
  about the
  extensive use of Generics in 1.4 once it is released.  This may make
  it
  easier to transition.  Maybe not.  At least let's be open to
  discussing it.
 
  Finally, in answer to the point about negating the point of
  generics, I
  respectfully disagree.  One major point of generics is to avoid code
  duplication of boilerplate code.   It it weren't for the need to
  create
  constructors, there wouldn't be any duplicated code.  I agree that
  it is a
  fine balance to strike, but there are competing needs of readability
  and
  maintainability.
 
  -Doug
 
 
  Hoover, William wrote:
 
  imho, that seems like that adds a lot of unnecessary code. One of the
  nice things about Wicket is that it keeps the bloat to a minimum.
 
  -Original Message-
  From: Doug Donohoe [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, May 14, 2008 8:21 AM
  To: users@wicket.apache.org
  Subject: Re: Using generics with some non-generic classes in Wicket
 
 
  Somewhat related to this thread, when I moved to generics win Wicket
  1.4,  I created some utility classes such as:
 
  public class VoidContainer extends WebMarkupContainerlt;Void public
  class VoidPanel extends Panellt;Void public class StringLabel
  extends
  Labellt;String
 
  public class IntegerModel extends Modellt;Integer public class
  StringModel extends Modellt;String public class DateModel extends
  Modellt;Date public class DoubleModel extends Modellt;Double
 
  And so on.  This made my wicket code cleaner and easier to use.  I
  think
  the Wicket 1.4 generics implementation is headed in the right
  direction.
  It was a pain at first because I had to parameterize everything, but
  creating convenience classes like this made it easier.
 
  I'm thinking about creating a patch with a suite of these types of
  classes because I think users will want something like this.
 
  -Doug
 
 
  Johan Compagner wrote:
 
  The problem is that wicket needs an annotation
 
  genericsOptional
 
  so that all the warnings about raw types are gone.
 
  A component only has to be generic if you use the IModel constructor
  or call getModel(), getModelObject() methods..
  for the rest it is not really needed
 
  johan
 
  On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk
  [EMAIL PROTECTED]
  wrote:
 
  My post kind of missed the point, I shouldn't post when I'm already
  half asleep. :-)
 
  Obviously MarkupContainer satisfies the MarkupContainer? in a
  method argument, so it accepts the raw type. However, it
  generates a
  warning because the method says it's generified, so you should

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

so why dont we store the integer in the model then? save an extra
memory slot, because if you make it Void then no one can set the
modelobject anyways.

-igor

On Wed, May 14, 2008 at 8:28 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 hmm i will make it Void
 because the LoopItem doesnt really have a model with an Integer in the
 model..
 it has an primitive int itself stored in it self.

 johan


 On Wed, May 14, 2008 at 4:52 PM, Stefan Simik [EMAIL PROTECTED]
 wrote:


 Great, it work without warnings now ;)

 Joham, could you please change the following class too ?

 file: Loop.java
 line:53
 from:   LoopItem extends WebMarkupContainer
 to:  LoopItem extends WebMarkupContainerInteger

 thx ;)
 Stefan




 Johan Compagner wrote:
 
  i already did the commit just yet..
 
  i did make them all   because i think people generally dont want to
  generify them anyway (use the model object)
 
 
 
  On Tue, May 13, 2008 at 9:48 PM, Stefan Simik [EMAIL PROTECTED]
  wrote:
 
 
  please, and will be these classes later generified ?
  Or should I make a RFE, or can I help anyway-for example attach a patch
 ?
 
  I love your work and Wicket, so I do my best, to make it better ;)
 
  Stefan Simik
 
 
 
 
 
 
  Johan Compagner wrote:
  
   yes thats the reason
  
   you are calling the method add with a generified component but that
   container itself is not generified
  
   i dont like this about generics expecially the onces like this:
  
   add(MarkupContainer? container)
  
   then suddenly a none generified component cant be added...
   thats really stupid ? should mean anything.. including none generics
  
   johan
  
  
   On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
 
   wrote:
  
  
   I have one idea,
  
   the reason of the warnigs is, that parent of AjaxPagingNavigator is
   PagingNavigator,
   which has parent Panel --- that is not parameterized.
  
   The same problem is with LoopItem, which extends the
   WebMarkupContainer --- that is not parameterized.
  
   ? could this be the reason ?
  
  
  
  
  
  
   Stefan Simik wrote:
   
Mhmm, it is meaningful ;) I will know in future, thx
   
One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.
   
Example:  I have a simple AjaxPagingNavigator, to which I add a
  simple
ListView
   
  ---
ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here
   
The warning says:
Type safety: The method add(Component...) belongs to the raw type
MarkupContainer.
References to generic type MarkupContainerT should be
  parameterized
   
I cannot find out, what's the warning reason, because ListView self
  is
parameterized.
   
   
  
   --
   View this message in context:
  
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216869.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17233011.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

That would cost more memory then it would gain

Now it is just 1 int field.. And do know that model isnt a field any
more by itself on component. Ok it is still a reference but that is
shared by behaviours and metadata.

So if we set it in a model, we would have created the model object
with a reference to a created Integer object that has the int value...
And that is stored in component, now if there is no metadata or
behavior then that cost nothing but if there was then everything cost
more..

On 5/14/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
 so why dont we store the integer in the model then? save an extra
 memory slot, because if you make it Void then no one can set the
 modelobject anyways.

 -igor

 On Wed, May 14, 2008 at 8:28 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
 hmm i will make it Void
 because the LoopItem doesnt really have a model with an Integer in the
 model..
 it has an primitive int itself stored in it self.

 johan


 On Wed, May 14, 2008 at 4:52 PM, Stefan Simik [EMAIL PROTECTED]
 wrote:


 Great, it work without warnings now ;)

 Joham, could you please change the following class too ?

 file: Loop.java
 line:53
 from:   LoopItem extends WebMarkupContainer
 to:  LoopItem extends WebMarkupContainerInteger

 thx ;)
 Stefan




 Johan Compagner wrote:
 
  i already did the commit just yet..
 
  i did make them all   because i think people generally dont want to
  generify them anyway (use the model object)
 
 
 
  On Tue, May 13, 2008 at 9:48 PM, Stefan Simik [EMAIL PROTECTED]
  wrote:
 
 
  please, and will be these classes later generified ?
  Or should I make a RFE, or can I help anyway-for example attach a
  patch
 ?
 
  I love your work and Wicket, so I do my best, to make it better ;)
 
  Stefan Simik
 
 
 
 
 
 
  Johan Compagner wrote:
  
   yes thats the reason
  
   you are calling the method add with a generified component but that
   container itself is not generified
  
   i dont like this about generics expecially the onces like this:
  
   add(MarkupContainer? container)
  
   then suddenly a none generified component cant be added...
   thats really stupid ? should mean anything.. including none
   generics
  
   johan
  
  
   On Tue, May 13, 2008 at 5:55 PM, Stefan Simik
   [EMAIL PROTECTED]
 
   wrote:
  
  
   I have one idea,
  
   the reason of the warnigs is, that parent of AjaxPagingNavigator is
   PagingNavigator,
   which has parent Panel --- that is not parameterized.
  
   The same problem is with LoopItem, which extends the
   WebMarkupContainer --- that is not parameterized.
  
   ? could this be the reason ?
  
  
  
  
  
  
   Stefan Simik wrote:
   
Mhmm, it is meaningful ;) I will know in future, thx
   
One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.
   
Example:  I have a simple AjaxPagingNavigator, to which I add a
  simple
ListView
   
  ---
ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here
   
The warning says:
Type safety: The method add(Component...) belongs to the raw
type
MarkupContainer.
References to generic type MarkupContainerT should be
  parameterized
   
I cannot find out, what's the warning reason, because ListView
self
  is
parameterized.
   
   
  
   --
   View this message in context:
  
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216869.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17233011.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

so i just implemented IAuthorizationStrategy and on this line in my class:

public boolean isInstantiationAuthorized(Class ? extends Component
componentClass)

i get: Component is a raw type. References to generic type
ComponentT should be parameterized

so that means we have to change our sig to ? extends Component?
but then we are back to the problem described in this thread.

generics suck.

-igor

On Wed, May 14, 2008 at 12:12 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 I dont think that user gets a warning if a param is of raw type. But
 we have a warning there.
 The problem is that for example MarkupContainer.add(Component) or
 IVisitor.visit(Component) i dont care what component is put in
 generified or not.
 In add it really doesnt matter because we dont do anything with it.
 With visitor it is different because the user could use it inside the
 method. But it should be useable without warnings for generified and
 none generfied components..


 On 5/14/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
 if we have a signature that accepts a raw type, will that also cause a
 warning in user's code?

 also having those suppress annotations practically _everywhere_ will be
 annoying

 -igor


 On Tue, May 13, 2008 at 11:56 PM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  I dont care, because i cant do any thing with the ? The only thing it
   enforces is that it must now be a generic class which is annoying. Not
   to mention that in that area eclipse and javac accept different
   things
 
   So or we in wicket dont use ? any where and have supress warning
   everywhere for that or we do use it and then suddenly it is in my eyes
   restricted to much.
 
 
 
   On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
Johan Compagner wrote:
 yes thats the reason

 you are calling the method add with a generified component but that
 container itself is not generified

 i dont like this about generics expecially the onces like this:

 add(MarkupContainer? container)

 then suddenly a none generified component cant be added...
 thats really stupid ? should mean anything.. including none
 generics
   
No, that's not correct. For example, List? is much more restrictive
than a raw List (which is a ListObject). To a raw list you can add an
instance of any type whatever, i.e., list.add(new Object()). But in
List? the ? is a wildcard which says it could be any type there,
 i.e.,
it could be a ListInteger. But you can't add a new Object() to a
ListInteger!
   
Thus MarkupContainer? means MarkupContainer parameterized by some
unknown type, and *not* MarkupContainer parameterized by Object, which
is what the raw type means.
   
Regards,
Sebastiaan
   
 johan


 On Tue, May 13, 2008 at 5:55 PM, Stefan Simik
 [EMAIL PROTECTED]
 wrote:

 I have one idea,

 the reason of the warnigs is, that parent of AjaxPagingNavigator is
 PagingNavigator,
 which has parent Panel --- that is not parameterized.

 The same problem is with LoopItem, which extends the
 WebMarkupContainer --- that is not parameterized.

 ? could this be the reason ?






 Stefan Simik wrote:
 Mhmm, it is meaningful ;) I will know in future, thx

 One of the last occuring warning is, when working with
 MarkupContainer#add(...)  or  #addOrReplace(...)  method.

 Example:  I have a simple AjaxPagingNavigator, to which I add a
 simple
 ListView

 ---
 ListViewInteger menu = new ListViewInteger(id, numbers){
 //populate metods
 }
 add(menu);//warning here

 The warning says:
 Type safety: The method add(Component...) belongs to the raw type
 MarkupContainer.
 References to generic type MarkupContainerT should be
 parameterized

 I cannot find out, what's the warning reason, because ListView self
 is
 parameterized.


 --
 View this message in context:

   
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
 Sent from the Wicket - User mailing list archive at Nabble.com.



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



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

yes then all the call to that method must be of a generic type.
cant be raw

i dont know what are we going to do in wicket i think we should decide it
should we just where we dont care about generic delete/not use the ? and
then
supresswarning?

johan


On Wed, May 14, 2008 at 9:45 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:

 so i just implemented IAuthorizationStrategy and on this line in my class:

 public boolean isInstantiationAuthorized(Class ? extends Component
 componentClass)

 i get: Component is a raw type. References to generic type
 ComponentT should be parameterized

 so that means we have to change our sig to ? extends Component?
 but then we are back to the problem described in this thread.

 generics suck.

 -igor

 On Wed, May 14, 2008 at 12:12 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  I dont think that user gets a warning if a param is of raw type. But
  we have a warning there.
  The problem is that for example MarkupContainer.add(Component) or
  IVisitor.visit(Component) i dont care what component is put in
  generified or not.
  In add it really doesnt matter because we dont do anything with it.
  With visitor it is different because the user could use it inside the
  method. But it should be useable without warnings for generified and
  none generfied components..
 
 
  On 5/14/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
  if we have a signature that accepts a raw type, will that also cause a
  warning in user's code?
 
  also having those suppress annotations practically _everywhere_ will be
  annoying
 
  -igor
 
 
  On Tue, May 13, 2008 at 11:56 PM, Johan Compagner [EMAIL PROTECTED]
 
  wrote:
   I dont care, because i cant do any thing with the ? The only thing it
enforces is that it must now be a generic class which is annoying.
 Not
to mention that in that area eclipse and javac accept different
things
  
So or we in wicket dont use ? any where and have supress warning
everywhere for that or we do use it and then suddenly it is in my
 eyes
restricted to much.
  
  
  
On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 Johan Compagner wrote:
  yes thats the reason
 
  you are calling the method add with a generified component but
 that
  container itself is not generified
 
  i dont like this about generics expecially the onces like this:
 
  add(MarkupContainer? container)
 
  then suddenly a none generified component cant be added...
  thats really stupid ? should mean anything.. including none
  generics

 No, that's not correct. For example, List? is much more
 restrictive
 than a raw List (which is a ListObject). To a raw list you can
 add an
 instance of any type whatever, i.e., list.add(new Object()). But in
 List? the ? is a wildcard which says it could be any type there,
  i.e.,
 it could be a ListInteger. But you can't add a new Object() to a
 ListInteger!

 Thus MarkupContainer? means MarkupContainer parameterized by
 some
 unknown type, and *not* MarkupContainer parameterized by Object,
 which
 is what the raw type means.

 Regards,
 Sebastiaan

  johan
 
 
  On Tue, May 13, 2008 at 5:55 PM, Stefan Simik
  [EMAIL PROTECTED]
  wrote:
 
  I have one idea,
 
  the reason of the warnigs is, that parent of AjaxPagingNavigator
 is
  PagingNavigator,
  which has parent Panel --- that is not parameterized.
 
  The same problem is with LoopItem, which extends the
  WebMarkupContainer --- that is not parameterized.
 
  ? could this be the reason ?
 
 
 
 
 
 
  Stefan Simik wrote:
  Mhmm, it is meaningful ;) I will know in future, thx
 
  One of the last occuring warning is, when working with
  MarkupContainer#add(...)  or  #addOrReplace(...)  method.
 
  Example:  I have a simple AjaxPagingNavigator, to which I add a
  simple
  ListView
 
  ---
  ListViewInteger menu = new ListViewInteger(id, numbers){
  //populate metods
  }
  add(menu);//warning here
 
  The warning says:
  Type safety: The method add(Component...) belongs to the raw
 type
  MarkupContainer.
  References to generic type MarkupContainerT should be
  parameterized
 
  I cannot find out, what's the warning reason, because ListView
 self
  is
  parameterized.
 
 
  --
  View this message in context:
 

 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

then our users have to suppress warnings in their code, which is
unacceptable at least to me. the whole generics thing turned out to be
quiet a lot crappier then i thought it would.

-igor


On Wed, May 14, 2008 at 12:48 PM, Johan Compagner [EMAIL PROTECTED] wrote:
 yes then all the call to that method must be of a generic type.
 cant be raw

 i dont know what are we going to do in wicket i think we should decide it
 should we just where we dont care about generic delete/not use the ? and
 then
 supresswarning?

 johan


 On Wed, May 14, 2008 at 9:45 PM, Igor Vaynberg [EMAIL PROTECTED]
 wrote:

 so i just implemented IAuthorizationStrategy and on this line in my class:

 public boolean isInstantiationAuthorized(Class ? extends Component
 componentClass)

 i get: Component is a raw type. References to generic type
 ComponentT should be parameterized

 so that means we have to change our sig to ? extends Component?
 but then we are back to the problem described in this thread.

 generics suck.

 -igor

 On Wed, May 14, 2008 at 12:12 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  I dont think that user gets a warning if a param is of raw type. But
  we have a warning there.
  The problem is that for example MarkupContainer.add(Component) or
  IVisitor.visit(Component) i dont care what component is put in
  generified or not.
  In add it really doesnt matter because we dont do anything with it.
  With visitor it is different because the user could use it inside the
  method. But it should be useable without warnings for generified and
  none generfied components..
 
 
  On 5/14/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
  if we have a signature that accepts a raw type, will that also cause a
  warning in user's code?
 
  also having those suppress annotations practically _everywhere_ will be
  annoying
 
  -igor
 
 
  On Tue, May 13, 2008 at 11:56 PM, Johan Compagner [EMAIL PROTECTED]
 
  wrote:
   I dont care, because i cant do any thing with the ? The only thing it
enforces is that it must now be a generic class which is annoying.
 Not
to mention that in that area eclipse and javac accept different
things
  
So or we in wicket dont use ? any where and have supress warning
everywhere for that or we do use it and then suddenly it is in my
 eyes
restricted to much.
  
  
  
On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 Johan Compagner wrote:
  yes thats the reason
 
  you are calling the method add with a generified component but
 that
  container itself is not generified
 
  i dont like this about generics expecially the onces like this:
 
  add(MarkupContainer? container)
 
  then suddenly a none generified component cant be added...
  thats really stupid ? should mean anything.. including none
  generics

 No, that's not correct. For example, List? is much more
 restrictive
 than a raw List (which is a ListObject). To a raw list you can
 add an
 instance of any type whatever, i.e., list.add(new Object()). But in
 List? the ? is a wildcard which says it could be any type there,
  i.e.,
 it could be a ListInteger. But you can't add a new Object() to a
 ListInteger!

 Thus MarkupContainer? means MarkupContainer parameterized by
 some
 unknown type, and *not* MarkupContainer parameterized by Object,
 which
 is what the raw type means.

 Regards,
 Sebastiaan

  johan
 
 
  On Tue, May 13, 2008 at 5:55 PM, Stefan Simik
  [EMAIL PROTECTED]
  wrote:
 
  I have one idea,
 
  the reason of the warnigs is, that parent of AjaxPagingNavigator
 is
  PagingNavigator,
  which has parent Panel --- that is not parameterized.
 
  The same problem is with LoopItem, which extends the
  WebMarkupContainer --- that is not parameterized.
 
  ? could this be the reason ?
 
 
 
 
 
 
  Stefan Simik wrote:
  Mhmm, it is meaningful ;) I will know in future, thx
 
  One of the last occuring warning is, when working with
  MarkupContainer#add(...)  or  #addOrReplace(...)  method.
 
  Example:  I have a simple AjaxPagingNavigator, to which I add a
  simple
  ListView
 
  ---
  ListViewInteger menu = new ListViewInteger(id, numbers){
  //populate metods
  }
  add(menu);//warning here
 
  The warning says:
  Type safety: The method add(Component...) belongs to the raw
 type
  MarkupContainer.
  References to generic type MarkupContainerT should be
  parameterized
 
  I cannot find out, what's the warning reason, because ListView
 self
  is
  parameterized.
 
 
  --
  View this message in context:
 

 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
  Sent

Re: Using generics with some non-generic classes in Wicket

[Sebastiaan van Erk]

 to the raw

type

   MarkupContainer.
   References to generic type MarkupContainerT should be

parameterized

  
   I cannot find out, what's the warning reason, because ListView

self

is

   parameterized.
  
  
   --
   View this message in context:
  
 

http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html

   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
  

-

   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]



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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

: The method add(Component...) belongs to the
 raw
  type
   MarkupContainer.
   References to generic type MarkupContainerT should be
   parameterized
  
   I cannot find out, what's the warning reason, because
 ListView
  self
   is
   parameterized.
  
  
   --
   View this message in context:
  
 
  
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
   Sent from the Wicket - User mailing list archive at
 Nabble.com.
  
  
  
   -
   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]
  
  
  
   -
   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]

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

 ?
  
  
  
  
  
  
   Stefan Simik wrote:
   Mhmm, it is meaningful ;) I will know in future, thx
  
   One of the last occuring warning is, when working with
   MarkupContainer#add(...)  or  #addOrReplace(...)  method.
  
   Example:  I have a simple AjaxPagingNavigator, to which I
 add a
   simple
   ListView
  
  
 ---
   ListViewInteger menu = new ListViewInteger(id,
 numbers){
   //populate metods
   }
   add(menu);//warning here
  
   The warning says:
   Type safety: The method add(Component...) belongs to the
 raw
  type
   MarkupContainer.
   References to generic type MarkupContainerT should be
   parameterized
  
   I cannot find out, what's the warning reason, because
 ListView
  self
   is
   parameterized.
  
  
   --
   View this message in context:
  
 
  
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
   Sent from the Wicket - User mailing list archive at
 Nabble.com.
  
  
  
   -
   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]
  
  
  
   -
   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]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Peter Ertl]

 should be

parameterized


I cannot find out, what's the warning reason, because

ListView

self

is

parameterized.



--
View this message in context:








http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html

Sent from the Wicket - User mailing list archive at

Nabble.com.





-

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]




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





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

  
johan
   
   
On Tue, May 13, 2008 at 5:55 PM, Stefan Simik

 [EMAIL PROTECTED]

wrote:
   
I have one idea,
   
the reason of the warnigs is, that parent of
 AjaxPagingNavigator

 is

PagingNavigator,
which has parent Panel --- that is not parameterized.
   
The same problem is with LoopItem, which extends the
WebMarkupContainer --- that is not parameterized.
   
? could this be the reason ?
   
   
   
   
   
   
Stefan Simik wrote:
Mhmm, it is meaningful ;) I will know in future, thx
   
One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.
   
Example:  I have a simple AjaxPagingNavigator, to which I add
 a

 simple

ListView
   


 ---

ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here
   
The warning says:
Type safety: The method add(Component...) belongs to the raw

 type

MarkupContainer.
References to generic type MarkupContainerT should be

 parameterized

   
I cannot find out, what's the warning reason, because ListView

 self

 is

parameterized.
   
   
--
View this message in context:
   
  


 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html

Sent from the Wicket - User mailing list archive at Nabble.com.
   
   
   

 -

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]


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



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

 AjaxPagingNavigator, to which I

 add a

 simple

 ListView


 ---

 ListViewInteger menu = new ListViewInteger(id,

 numbers){

   //populate metods
 }
 add(menu);//warning here

 The warning says:
 Type safety: The method add(Component...) belongs to the

 raw

 type

 MarkupContainer.
 References to generic type MarkupContainerT should be

 parameterized

 I cannot find out, what's the warning reason, because

 ListView

 self

 is

 parameterized.


 --
 View this message in context:





 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html

 Sent from the Wicket - User mailing list archive at

 Nabble.com.



 -

 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]



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




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

Re: Using generics with some non-generic classes in Wicket

[Peter Ertl]

 --- that is not parameterized.

? could this be the reason ?






Stefan Simik wrote:


Mhmm, it is meaningful ;) I will know in future, thx

One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.

Example:  I have a simple AjaxPagingNavigator, to which I


add a


simple


ListView




---


ListViewInteger menu = new ListViewInteger(id,


numbers){


 //populate metods
}
add(menu);//warning here

The warning says:
Type safety: The method add(Component...) belongs to the


raw


type


MarkupContainer.
References to generic type MarkupContainerT should be


parameterized


I cannot find out, what's the warning reason, because


ListView


self


is


parameterized.



--
View this message in context:









http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html


Sent from the Wicket - User mailing list archive at


Nabble.com.





-


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]




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





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

Re: Using generics with some non-generic classes in Wicket

[Sebastiaan van Erk]

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: ComponentObject if you don't want to 
constrain the model object, and ComponentVoid 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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using generics with some non-generic classes in Wicket

[Eelco Hillenius]

 the whole generics thing turned out to be
 quiet a lot crappier then i thought it would.

:-)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

since then the thread has evolved into whether or not we should use ?
extends Component or ? extends Component?

-igor


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: ComponentObject if you don't want to constrain the
 model object, and ComponentVoid 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]

Re: Using generics with some non-generic classes in Wicket

[Eelco Hillenius]

On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
 the whole generics thing turned out to be
 quiet a lot crappier then i thought it would.

 :-)

Generics for models: great. Generics for components: awful. Too bad
that stuff is contagious.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Peter Ertl]

wicket 1.6 = scala-based ? *lol*


Am 14.05.2008 um 23:28 schrieb Eelco Hillenius:


On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:

the whole generics thing turned out to be
quiet a lot crappier then i thought it would.


:-)


Generics for models: great. Generics for components: awful. Too bad
that stuff is contagious.

Eelco

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

Re: Using generics with some non-generic classes in Wicket

[Sebastiaan van Erk]

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: ComponentObject if you don't want to constrain the
model object, and ComponentVoid 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]



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

yeah, generics are pretty damn viral

-igor

On Wed, May 14, 2008 at 2:28 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
 On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
 [EMAIL PROTECTED] wrote:
 the whole generics thing turned out to be
 quiet a lot crappier then i thought it would.

 :-)

 Generics for models: great. Generics for components: awful. Too bad
 that stuff is contagious.

 Eelco

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

Re: Using generics with some non-generic classes in Wicket

[Igor Vaynberg]

well, apparently johan ran into a situation where component? is too
restrictive...

-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: ComponentObject if you don't want to constrain the
 model object, and ComponentVoid 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]

Re: Using generics with some non-generic classes in Wicket

[Gerolf Seitz]

i think something similar happend to me with Model.valueOf(Map), so
i had to change it back to return Model instead of Model?

  Gerolf

On Wed, May 14, 2008 at 11:41 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:

 well, apparently johan ran into a situation where component? is too
 restrictive...

 -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: ComponentObject if you don't want to constrain the
  model object, and ComponentVoid 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]

Using generics with some non-generic classes in Wicket

[Stefan Simik]

Hi boys, 

I would like to ask something about wicket generics. I have a warning, that
I don't know, how to solve.

For example in such a line:  

IModelString model = new StringResourceModel( ... ); 

I have a warning, which I cannot remove: 
---
Type safety: The expression of type StringResourceModel needs unchecked
conversion to conform to IModelString


Why is the StringResourceModel (and some other classes) not generified ?
Will they be later,
or is there any problem with generifying of these classes ?

Thx,
Stefan Simik




-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17208928.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

the only thing i can quickly come up with is this

public ExtendLabel(String id, T string)
{
super(id, new ModelT(string));
}




On Tue, May 13, 2008 at 4:55 PM, Stefan Simik [EMAIL PROTECTED]
wrote:


 Thx Maurice, your are right. I was using Wicket 1.4M1.
 I checked out latest from trunk, and it OK. ;)

 So another problematic compiler warning.
 For example  simple  - subtype of Label, which has model type of anything
 Serializable.



 public class ExtendedLabellt;T extends Serializablegt; extends
 Labellt;Tgt{

   private IStringProvider stringProvider = null;


   public ExtendedLabel(String id, IModel model, IStringProvider
 stringProvider) {
super(id, model);
this.stringProvider = stringProvider;
   }

   public ExtendedLabel(String id, String text) {
this(id, new Model(text), new BasicStringProvider());
//this(id, new Modellt;Tgt;(text), new BasicStringProvider());
 //error
   }

 }




 The problematic part, is the second constructor, which calls this. Its
 second parameter - new Model(text),

 which I cannot generify. If I write new Model(text), I get an error:
 The
 constructor Model(String) is undefined.


 I can't find out, what I am doing wrong.


 Thx

 Stefan Simik





 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17210525.html
 Sent from the Wicket - User mailing list archive at Nabble.com.

Re: Using generics with some non-generic classes in Wicket

[Stefan Simik]

Uuf, great :)  It works !  Thx. 

But, is not String something Serializable ? 
I cannot understand where was the problem,
but I know, this is more about Java Generics, not about Wicket.




Johan Compagner wrote:
 
 the only thing i can quickly come up with is this
 
 public ExtendLabel(String id, T string)
 {
 super(id, new ModelT(string));
 }
 

-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17211220.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Stefan Simik]

Thx Maurice, your are right. I was using Wicket 1.4M1.
I checked out latest from trunk, and it OK. ;)

So another problematic compiler warning. 
For example  simple  - subtype of Label, which has model type of anything
Serializable.



public class ExtendedLabellt;T extends Serializablegt; extends
Labellt;Tgt{

   private IStringProvider stringProvider = null;


   public ExtendedLabel(String id, IModel model, IStringProvider
stringProvider) {
super(id, model);
this.stringProvider = stringProvider;
   }

   public ExtendedLabel(String id, String text) {
this(id, new Model(text), new BasicStringProvider());
//this(id, new Modellt;Tgt;(text), new BasicStringProvider());
//error
   }

}




The problematic part, is the second constructor, which calls this. Its
second parameter - new Model(text), 

which I cannot generify. If I write new Model(text), I get an error: The
constructor Model(String) is undefined.   


I can't find out, what I am doing wrong.


Thx

Stefan Simik





-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17210525.html
Sent from the Wicket - User mailing list archive at Nabble.com.

Re: Using generics with some non-generic classes in Wicket

[Stefan Simik]

Mhmm, it is meaningful ;) I will know in future, thx

One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.

Example:  I have a simple AjaxPagingNavigator, to which I add a simple
ListView
---
ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here

The warning says: 
Type safety: The method add(Component...) belongs to the raw type
MarkupContainer. 
References to generic type MarkupContainerT should be parameterized

I cannot find out, what's the warning reason, because ListView self is
parameterized. 

-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17211948.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Stefan Simik]

I have one idea,

the reason of the warnigs is, that parent of AjaxPagingNavigator is
PagingNavigator,
which has parent Panel --- that is not parameterized.

The same problem is with LoopItem, which extends the
WebMarkupContainer --- that is not parameterized.

? could this be the reason ?






Stefan Simik wrote:
 
 Mhmm, it is meaningful ;) I will know in future, thx
 
 One of the last occuring warning is, when working with
 MarkupContainer#add(...)  or  #addOrReplace(...)  method.
 
 Example:  I have a simple AjaxPagingNavigator, to which I add a simple
 ListView
 ---
 ListViewInteger menu = new ListViewInteger(id, numbers){
 //populate metods
 }
 add(menu);//warning here
 
 The warning says: 
 Type safety: The method add(Component...) belongs to the raw type
 MarkupContainer. 
 References to generic type MarkupContainerT should be parameterized
 
 I cannot find out, what's the warning reason, because ListView self is
 parameterized. 
 
 

-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Jonathan Locke]

well, unless this:

  public class LabelT extends WebComponentT

became:

  public class Label extends WebComponentString

not saying this is the right thing to do as it might break a lot of code,
but it would be more precise.


Johan Compagner wrote:
 
 the only thing i can quickly come up with is this
 
 public ExtendLabel(String id, T string)
 {
 super(id, new ModelT(string));
 }
 
 
 
 
 On Tue, May 13, 2008 at 4:55 PM, Stefan Simik [EMAIL PROTECTED]
 wrote:
 

 Thx Maurice, your are right. I was using Wicket 1.4M1.
 I checked out latest from trunk, and it OK. ;)

 So another problematic compiler warning.
 For example  simple  - subtype of Label, which has model type of anything
 Serializable.



 public class ExtendedLabellt;T extends Serializablegt; extends
 Labellt;Tgt{

   private IStringProvider stringProvider = null;


   public ExtendedLabel(String id, IModel model, IStringProvider
 stringProvider) {
super(id, model);
this.stringProvider = stringProvider;
   }

   public ExtendedLabel(String id, String text) {
this(id, new Model(text), new BasicStringProvider());
//this(id, new Modellt;Tgt;(text), new BasicStringProvider());
 //error
   }

 }




 The problematic part, is the second constructor, which calls this. Its
 second parameter - new Model(text),

 which I cannot generify. If I write new Model(text), I get an error:
 The
 constructor Model(String) is undefined.


 I can't find out, what I am doing wrong.


 Thx

 Stefan Simik





 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17210525.html
 Sent from the Wicket - User mailing list archive at Nabble.com.

 
 

-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17212325.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

cant i have a Label that has a Date as a object?
That is resolved by the converter for display?

johan


On Tue, May 13, 2008 at 6:09 PM, Jonathan Locke [EMAIL PROTECTED]
wrote:



 well, unless this:

  public class LabelT extends WebComponentT

 became:

  public class Label extends WebComponentString

 not saying this is the right thing to do as it might break a lot of code,
 but it would be more precise.


 Johan Compagner wrote:
 
  the only thing i can quickly come up with is this
 
  public ExtendLabel(String id, T string)
  {
  super(id, new ModelT(string));
  }
 
 
 
 
  On Tue, May 13, 2008 at 4:55 PM, Stefan Simik [EMAIL PROTECTED]
  wrote:
 
 
  Thx Maurice, your are right. I was using Wicket 1.4M1.
  I checked out latest from trunk, and it OK. ;)
 
  So another problematic compiler warning.
  For example  simple  - subtype of Label, which has model type of
 anything
  Serializable.
 
 
 
  public class ExtendedLabellt;T extends Serializablegt; extends
  Labellt;Tgt{
 
private IStringProvider stringProvider = null;
 
 
public ExtendedLabel(String id, IModel model, IStringProvider
  stringProvider) {
 super(id, model);
 this.stringProvider = stringProvider;
}
 
public ExtendedLabel(String id, String text) {
 this(id, new Model(text), new BasicStringProvider());
 //this(id, new Modellt;Tgt;(text), new BasicStringProvider());
  //error
}
 
  }
 
 
 
 
  The problematic part, is the second constructor, which calls this. Its
  second parameter - new Model(text),
 
  which I cannot generify. If I write new Model(text), I get an error:
  The
  constructor Model(String) is undefined.
 
 
  I can't find out, what I am doing wrong.
 
 
  Thx
 
  Stefan Simik
 
 
 
 
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17210525.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17212325.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Stefan Simik]

please, and will be these classes later generified ? 
Or should I make a RFE, or can I help anyway-for example attach a patch ?

I love your work and Wicket, so I do my best, to make it better ;)

Stefan Simik






Johan Compagner wrote:
 
 yes thats the reason
 
 you are calling the method add with a generified component but that
 container itself is not generified
 
 i dont like this about generics expecially the onces like this:
 
 add(MarkupContainer? container)
 
 then suddenly a none generified component cant be added...
 thats really stupid ? should mean anything.. including none generics
 
 johan
 
 
 On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
 wrote:
 

 I have one idea,

 the reason of the warnigs is, that parent of AjaxPagingNavigator is
 PagingNavigator,
 which has parent Panel --- that is not parameterized.

 The same problem is with LoopItem, which extends the
 WebMarkupContainer --- that is not parameterized.

 ? could this be the reason ?






 Stefan Simik wrote:
 
  Mhmm, it is meaningful ;) I will know in future, thx
 
  One of the last occuring warning is, when working with
  MarkupContainer#add(...)  or  #addOrReplace(...)  method.
 
  Example:  I have a simple AjaxPagingNavigator, to which I add a simple
  ListView
  ---
  ListViewInteger menu = new ListViewInteger(id, numbers){
  //populate metods
  }
  add(menu);//warning here
 
  The warning says:
  Type safety: The method add(Component...) belongs to the raw type
  MarkupContainer.
  References to generic type MarkupContainerT should be parameterized
 
  I cannot find out, what's the warning reason, because ListView self is
  parameterized.
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 

-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216869.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

i already did the commit just yet..

i did make them all Object  because i think people generally dont want to
generify them anyway (use the model object)



On Tue, May 13, 2008 at 9:48 PM, Stefan Simik [EMAIL PROTECTED]
wrote:


 please, and will be these classes later generified ?
 Or should I make a RFE, or can I help anyway-for example attach a patch ?

 I love your work and Wicket, so I do my best, to make it better ;)

 Stefan Simik






 Johan Compagner wrote:
 
  yes thats the reason
 
  you are calling the method add with a generified component but that
  container itself is not generified
 
  i dont like this about generics expecially the onces like this:
 
  add(MarkupContainer? container)
 
  then suddenly a none generified component cant be added...
  thats really stupid ? should mean anything.. including none generics
 
  johan
 
 
  On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
  wrote:
 
 
  I have one idea,
 
  the reason of the warnigs is, that parent of AjaxPagingNavigator is
  PagingNavigator,
  which has parent Panel --- that is not parameterized.
 
  The same problem is with LoopItem, which extends the
  WebMarkupContainer --- that is not parameterized.
 
  ? could this be the reason ?
 
 
 
 
 
 
  Stefan Simik wrote:
  
   Mhmm, it is meaningful ;) I will know in future, thx
  
   One of the last occuring warning is, when working with
   MarkupContainer#add(...)  or  #addOrReplace(...)  method.
  
   Example:  I have a simple AjaxPagingNavigator, to which I add a
 simple
   ListView
  
 ---
   ListViewInteger menu = new ListViewInteger(id, numbers){
   //populate metods
   }
   add(menu);//warning here
  
   The warning says:
   Type safety: The method add(Component...) belongs to the raw type
   MarkupContainer.
   References to generic type MarkupContainerT should be
 parameterized
  
   I cannot find out, what's the warning reason, because ListView self
 is
   parameterized.
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216869.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Jonathan Locke]

have not thought it through.  i was just pointing out another option.
in some sense a label shows a string like a listview shows a list.  
that's all.


Johan Compagner wrote:
 
 cant i have a Label that has a Date as a object?
 That is resolved by the converter for display?
 
 johan
 
 
 On Tue, May 13, 2008 at 6:09 PM, Jonathan Locke [EMAIL PROTECTED]
 wrote:
 


 well, unless this:

  public class LabelT extends WebComponentT

 became:

  public class Label extends WebComponentString

 not saying this is the right thing to do as it might break a lot of code,
 but it would be more precise.


 Johan Compagner wrote:
 
  the only thing i can quickly come up with is this
 
  public ExtendLabel(String id, T string)
  {
  super(id, new ModelT(string));
  }
 
 
 
 
  On Tue, May 13, 2008 at 4:55 PM, Stefan Simik [EMAIL PROTECTED]
  wrote:
 
 
  Thx Maurice, your are right. I was using Wicket 1.4M1.
  I checked out latest from trunk, and it OK. ;)
 
  So another problematic compiler warning.
  For example  simple  - subtype of Label, which has model type of
 anything
  Serializable.
 
 
 
  public class ExtendedLabellt;T extends Serializablegt; extends
  Labellt;Tgt{
 
private IStringProvider stringProvider = null;
 
 
public ExtendedLabel(String id, IModel model, IStringProvider
  stringProvider) {
 super(id, model);
 this.stringProvider = stringProvider;
}
 
public ExtendedLabel(String id, String text) {
 this(id, new Model(text), new BasicStringProvider());
 //this(id, new Modellt;Tgt;(text), new
 BasicStringProvider());
  //error
}
 
  }
 
 
 
 
  The problematic part, is the second constructor, which calls this. Its
  second parameter - new Model(text),
 
  which I cannot generify. If I write new Model(text), I get an error:
  The
  constructor Model(String) is undefined.
 
 
  I can't find out, what I am doing wrong.
 
 
  Thx
 
  Stefan Simik
 
 
 
 
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17210525.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17212325.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 

-- 
View this message in context: 
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216943.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Johan Compagner]

yeah i know just wanted to give an example

But Label == String is not the really the same thing as ListView == List..

Because for a Label getModelObject() doesnt have to be a String (it can be
anything)
but for ListView.getModelObject() does have to be a List..

This is also because our converters sit between modelobject - string
representation.
So for a Listview a converter is not really used, as for a label it is used
or called for pretty much everytime.

johan



On Tue, May 13, 2008 at 9:52 PM, Jonathan Locke [EMAIL PROTECTED]
wrote:



 have not thought it through.  i was just pointing out another option.
 in some sense a label shows a string like a listview shows a list.
 that's all.


 Johan Compagner wrote:
 
  cant i have a Label that has a Date as a object?
  That is resolved by the converter for display?
 
  johan
 
 
  On Tue, May 13, 2008 at 6:09 PM, Jonathan Locke 
 [EMAIL PROTECTED]
  wrote:
 
 
 
  well, unless this:
 
   public class LabelT extends WebComponentT
 
  became:
 
   public class Label extends WebComponentString
 
  not saying this is the right thing to do as it might break a lot of
 code,
  but it would be more precise.
 
 
  Johan Compagner wrote:
  
   the only thing i can quickly come up with is this
  
   public ExtendLabel(String id, T string)
   {
   super(id, new ModelT(string));
   }
  
  
  
  
   On Tue, May 13, 2008 at 4:55 PM, Stefan Simik [EMAIL PROTECTED]
 
   wrote:
  
  
   Thx Maurice, your are right. I was using Wicket 1.4M1.
   I checked out latest from trunk, and it OK. ;)
  
   So another problematic compiler warning.
   For example  simple  - subtype of Label, which has model type of
  anything
   Serializable.
  
  
  
   public class ExtendedLabellt;T extends Serializablegt; extends
   Labellt;Tgt{
  
 private IStringProvider stringProvider = null;
  
  
 public ExtendedLabel(String id, IModel model, IStringProvider
   stringProvider) {
  super(id, model);
  this.stringProvider = stringProvider;
 }
  
 public ExtendedLabel(String id, String text) {
  this(id, new Model(text), new BasicStringProvider());
  //this(id, new Modellt;Tgt;(text), new
  BasicStringProvider());
   //error
 }
  
   }
  
  
  
  
   The problematic part, is the second constructor, which calls this.
 Its
   second parameter - new Model(text),
  
   which I cannot generify. If I write new Model(text), I get an
 error:
   The
   constructor Model(String) is undefined.
  
  
   I can't find out, what I am doing wrong.
  
  
   Thx
  
   Stefan Simik
  
  
  
  
  
   --
   View this message in context:
  
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17210525.html
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17212325.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216943.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using generics with some non-generic classes in Wicket

[Sebastiaan van Erk]

Johan Compagner wrote:

yes thats the reason

you are calling the method add with a generified component but that
container itself is not generified

i dont like this about generics expecially the onces like this:

add(MarkupContainer? container)

then suddenly a none generified component cant be added...
thats really stupid ? should mean anything.. including none generics


No, that's not correct. For example, List? is much more restrictive 
than a raw List (which is a ListObject). To a raw list you can add an 
instance of any type whatever, i.e., list.add(new Object()). But in 
List? the ? is a wildcard which says it could be any type there, i.e., 
it could be a ListInteger. But you can't add a new Object() to a 
ListInteger!


Thus MarkupContainer? means MarkupContainer parameterized by some 
unknown type, and *not* MarkupContainer parameterized by Object, which 
is what the raw type means.


Regards,
Sebastiaan


johan


On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
wrote:


I have one idea,

the reason of the warnigs is, that parent of AjaxPagingNavigator is
PagingNavigator,
which has parent Panel --- that is not parameterized.

The same problem is with LoopItem, which extends the
WebMarkupContainer --- that is not parameterized.

? could this be the reason ?






Stefan Simik wrote:

Mhmm, it is meaningful ;) I will know in future, thx

One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.

Example:  I have a simple AjaxPagingNavigator, to which I add a simple
ListView
---
ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here

The warning says:
Type safety: The method add(Component...) belongs to the raw type
MarkupContainer.
References to generic type MarkupContainerT should be parameterized

I cannot find out, what's the warning reason, because ListView self is
parameterized.



--
View this message in context:
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






smime.p7s
Description: S/MIME Cryptographic Signature