subject:"RE\: \(Class\? extends Page\?\) casting troubles"


Martin Funk wrote:

Jeremy Thomerson wrote:

I haven't read the whole thread, but you should be fine as long as your
returned page class uses generics...

Here's what I use in one app, no warnings, no casts:

@Override
public Class? extends Page? getHomePage() {
return Home.class;
}


public class Home extends WebPageVoid {
}

  

Hi Jeremy,

I'm still picking on the words. What do you mean by 'uses generics'?

I think the point is class Home has to be a non generic type subclassing 
the generic class WebPage with a concrete type parameter.


Why should the HomePage class be non generic, and why should you use a 
concrete type parameter?


Class? extends Page? means class of (anything that extends (page of 
anything)).


That means your home page can have as many type parameters as you wish 
(or none at all), as long as it extends Page?. This also means you you 
can define a generic HomePage like this:


class HomePageT extends WebPageT { ... }

if you feel like it, and don't have to use a concrete type.

And I still really don't understand why java has a problem with this:

class HomePage extends WebPage { ... }

since here it *is still* the case that HomePage is a subtype of 
WebPage? (you prove this by the assignment:


WebPage? wp = new HomePage();

which works fine). So you would expect to be able to return this in the 
getHomePage() method. But you can't because the compiler chokes on it. I 
have not seen a convincing reason why this shouldn't work yet, though.


Regards,
Sebastiaan


mf

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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles

2008-06-06 Thread Martin Funk

2008/6/6 Sebastiaan van Erk [EMAIL PROTECTED]:

 Martin Funk wrote:

 Jeremy Thomerson wrote:

 I haven't read the whole thread, but you should be fine as long as your
 returned page class uses generics...

 Here's what I use in one app, no warnings, no casts:

@Override
public Class? extends Page? getHomePage() {
return Home.class;
}


 public class Home extends WebPageVoid {
 }



 Hi Jeremy,

 I'm still picking on the words. What do you mean by 'uses generics'?

 I think the point is class Home has to be a non generic type subclassing
 the generic class WebPage with a concrete type parameter.


 Why should the HomePage class be non generic, and why should you use a
 concrete type parameter?

I'm not good in explaining why HomePage has to be non generic yet, but there
seems to be experimental evidence, see:
http://cwiki.apache.org/confluence/display/WICKET/generics#generics-Variationsof%27publicvoidfoo%28Class%3C%3FextendsComponent%3C%3F%3E%3Eclazz%29%27

But the given class Home definitely is not generic!



 Class? extends Page? means class of (anything that extends (page of
 anything)).

I'm not so sure.



 That means your home page can have as many type parameters as you wish (or
 none at all), as long as it extends Page?. This also means you you can
 define a generic HomePage like this:

 class HomePageT extends WebPageT { ... }

see
foo.bar(Component.class);
foo.bar(IntegerComponent.class);
foo.bar(GenericComponent.class);
foo.bar(GenericIntegerComponent.class);
in the given example page above.



 if you feel like it, and don't have to use a concrete type.

But if you chose to make class HomePage non-generic you have to decide on a
concrete type parameter for WebPage.



 And I still really don't understand why java has a problem with this:

 class HomePage extends WebPage { ... }

 since here it *is still* the case that HomePage is a subtype of WebPage?
 (you prove this by the assignment:

 WebPage? wp = new HomePage();

 which works fine). So you would expect to be able to return this in the
 getHomePage() method. But you can't because the compiler chokes on it. I
 have not seen a convincing reason why this shouldn't work yet, though.

Me neither, but we are working on it.

Martin



 Regards,
 Sebastiaan

  mf

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

Re: (Class? extends Page?) casting troubles

2008-06-06 Thread Johan Compagner

No the HomePage cant be raw type anymore more
So it must be typed.. Why that is..?
? extends Page?

then the last ? seem to say that for that Class it must be filled in with
a real Type
So it must be HomePage extends PageString

and you can't do:

foo.bar(ComponentString.class)

because that doesnt mean anything
So

HomePageT extends PageT

then homePage class is still raw type

and HomePage extends PageString

then the class it self is generified

and somehow ? in a class definition does apply only to a Generified class
not a raw type class.

I think it is all in that area that it is a Class..

johan





On Fri, Jun 6, 2008 at 1:31 PM, Martin Funk [EMAIL PROTECTED]
wrote:

 2008/6/6 Sebastiaan van Erk [EMAIL PROTECTED]:

  Martin Funk wrote:
 
  Jeremy Thomerson wrote:
 
  I haven't read the whole thread, but you should be fine as long as your
  returned page class uses generics...
 
  Here's what I use in one app, no warnings, no casts:
 
 @Override
 public Class? extends Page? getHomePage() {
 return Home.class;
 }
 
 
  public class Home extends WebPageVoid {
  }
 
 
 
  Hi Jeremy,
 
  I'm still picking on the words. What do you mean by 'uses generics'?
 
  I think the point is class Home has to be a non generic type subclassing
  the generic class WebPage with a concrete type parameter.
 
 
  Why should the HomePage class be non generic, and why should you use a
  concrete type parameter?

 I'm not good in explaining why HomePage has to be non generic yet, but
 there
 seems to be experimental evidence, see:

 http://cwiki.apache.org/confluence/display/WICKET/generics#generics-Variationsof%27publicvoidfoo%28Class%3C%3FextendsComponent%3C%3F%3E%3Eclazz%29%27

 But the given class Home definitely is not generic!


 
  Class? extends Page? means class of (anything that extends (page of
  anything)).

 I'm not so sure.

 
 
  That means your home page can have as many type parameters as you wish
 (or
  none at all), as long as it extends Page?. This also means you you can
  define a generic HomePage like this:
 
  class HomePageT extends WebPageT { ... }

 see
foo.bar(Component.class);
foo.bar(IntegerComponent.class);
foo.bar(GenericComponent.class);
foo.bar(GenericIntegerComponent.class);
 in the given example page above.

 
 
  if you feel like it, and don't have to use a concrete type.

 But if you chose to make class HomePage non-generic you have to decide on a
 concrete type parameter for WebPage.

 
 
  And I still really don't understand why java has a problem with this:
 
  class HomePage extends WebPage { ... }
 
  since here it *is still* the case that HomePage is a subtype of
 WebPage?
  (you prove this by the assignment:
 
  WebPage? wp = new HomePage();
 
  which works fine). So you would expect to be able to return this in the
  getHomePage() method. But you can't because the compiler chokes on it. I
  have not seen a convincing reason why this shouldn't work yet, though.

 Me neither, but we are working on it.

 Martin

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

Re: (Class? extends Page?) casting troubles

2008-06-06 Thread Martin Funk


Sorry that I don't have any answers, but I have some comments.

Johan Compagner wrote:

No the HomePage cant be raw type anymore more
So it must be typed.. Why that is..?
? extends Page?

then the last ? seem to say that for that Class it must be filled in with
a real Type
So it must be HomePage extends PageString
  
This HomePage is not a 'raw type' it is a non-generic type extending the 
generic type Page with the type parameter String.

The term 'raw type' only applies when the type is generic.
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#What%20is%20the%20raw%20type?

class HomePage extends Page? is syntactically wrong a super type may not 
specify any wildcard whatsoever.

http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#Can%20I%20derive%20from%20a%20wildcard%20instantiation%20of%20a%20parameterized%20type?

and you can't do:

foo.bar(ComponentString.class)

because that doesnt mean anything
  

http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#Why%20is%20there%20no%20class%20literal%20for%20the%20concrete%20instantiation%20of%20a%20parameterized%20type?
+
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#Why%20is%20there%20no%20class%20literal%20for%20wildcard%20instantiations%20of%20a%20parameterized%20type?

So

HomePageT extends PageT

then homePage class is still raw type
  

It is not raw, s.o.

and HomePage extends PageString

then the class it self is generified
  

Depends on how you define generified, but it is not generic, thats for sure.

and somehow ? in a class definition does apply only to a Generified class
not a raw type class.

I think it is all in that area that it is a Class..

johan



  

my 50 cent,

Martin


On Fri, Jun 6, 2008 at 1:31 PM, Martin Funk [EMAIL PROTECTED]
wrote:

  

2008/6/6 Sebastiaan van Erk [EMAIL PROTECTED]:



Martin Funk wrote:

  

Jeremy Thomerson wrote:



I haven't read the whole thread, but you should be fine as long as your
returned page class uses generics...

Here's what I use in one app, no warnings, no casts:

   @Override
   public Class? extends Page? getHomePage() {
   return Home.class;
   }


public class Home extends WebPageVoid {
}



  

Hi Jeremy,

I'm still picking on the words. What do you mean by 'uses generics'?

I think the point is class Home has to be a non generic type subclassing
the generic class WebPage with a concrete type parameter.



Why should the HomePage class be non generic, and why should you use a
concrete type parameter?
  

I'm not good in explaining why HomePage has to be non generic yet, but
there
seems to be experimental evidence, see:

http://cwiki.apache.org/confluence/display/WICKET/generics#generics-Variationsof%27publicvoidfoo%28Class%3C%3FextendsComponent%3C%3F%3E%3Eclazz%29%27

But the given class Home definitely is not generic!




Class? extends Page? means class of (anything that extends (page of
anything)).
  

I'm not so sure.



That means your home page can have as many type parameters as you wish
  

(or


none at all), as long as it extends Page?. This also means you you can
define a generic HomePage like this:

class HomePageT extends WebPageT { ... }
  

see
   foo.bar(Component.class);
   foo.bar(IntegerComponent.class);
   foo.bar(GenericComponent.class);
   foo.bar(GenericIntegerComponent.class);
in the given example page above.



if you feel like it, and don't have to use a concrete type.
  

But if you chose to make class HomePage non-generic you have to decide on a
concrete type parameter for WebPage.



And I still really don't understand why java has a problem with this:

class HomePage extends WebPage { ... }

since here it *is still* the case that HomePage is a subtype of
  

WebPage?


(you prove this by the assignment:

WebPage? wp = new HomePage();

which works fine). So you would expect to be able to return this in the
getHomePage() method. But you can't because the compiler chokes on it. I
have not seen a convincing reason why this shouldn't work yet, though.
  

Me neither, but we are working on it.

Martin



Regards,
Sebastiaan

 mf
  

-
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: (Class? extends Page?) casting troubles


ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:

Martin Funk wrote:


Class? extends Page? means class of (anything that extends (page of
anything)).


I'm not so sure.


There are 2 separate issues:

ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
where RawBar extends Bar as a raw type. That is, given:


  static class FooT {
  }

  static class BarT {
  }

  static class RawBar extends Bar {
  }

  static class SubBarT extends BarT {
  }

Thus:

   Bar? bar = new RawBar(); // works, because RawBar is a subtype of 
Bar?


But:

   Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK - THIS 
IS CAUSING ONE HALF OF ALL OUR HEADACHES


(correction:)
   Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK - 
THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES


Btw, this does work (like you expect):
   Foo? extends Bar? rawbar2 = new FooSubBar?();

Note that this is the issue that complete baffles me, as RawBar is a 
subtype of Bar?, so I *really* *really* *REALLY* have no idea why the 
compiler chokes on this.


ISSUE 2: The class literal of a generic type returns a class of a raw 
type.  Thus Foo.class return ClassFoo. This is also really messed up, 
because:

ClassFoo fc = Foo.class;


compiles, but generates a warning (reference to raw type). But if you 
type this in eclipse:


x fc = Foo.class;

and use eclipse quickfix to change x to the correct type, it'll 
change it to precisely ClassFoo (the JLS is very short about this, see 
also 
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.8.2). 



So what the heck is the proper type for the class literal??? I couldn't 
find any!


Finally, note that when you define a method like this:

  static void method1(Foo? extends Bar? y) {
  }

it works like a charm for a new FooSubBarString, i.e., the Foo of 
(anything that extends (bar of anything)) really is the correct 
interpretation.


It's just that the interaction with raw types is completely *foobar* 
(pun intended).


Regards,
Sebastiaan









smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles

2008-06-06 Thread Martin Funk


Sebastiaan van Erk wrote:

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:

Martin Funk wrote:

Class? extends Page? means class of (anything that extends 
(page of

anything)).


I'm not so sure.


There are 2 separate issues:

ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
where RawBar extends Bar as a raw type. That is, given:


  static class FooT {
  }

  static class BarT {
  }

  static class RawBar extends Bar {
  }

  static class SubBarT extends BarT {
  }

Thus:

   Bar? bar = new RawBar(); // works, because RawBar is a subtype 
of Bar?


But:

   Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK - 
THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES


(correction:)
   Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK 
- THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES


Btw, this does work (like you expect):
   Foo? extends Bar? rawbar2 = new FooSubBar?();

maybe some more wisdom can be found here:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ209
In her words it would mean 'raw types are not part of the type family 
denoted by the wildcard parametrized type Bar?'
But I'm still puzzled, since taking that FAQ it doesn't explain why in 
the case of the generic method


public T extends Component? void dol(ClassT clazz)

the raw types are all of a sudden member of that family





Note that this is the issue that complete baffles me, as RawBar is a 
subtype of Bar?, so I *really* *really* *REALLY* have no idea why 
the compiler chokes on this.


ISSUE 2: The class literal of a generic type returns a class of a raw 
type.  Thus Foo.class return ClassFoo. This is also really messed 
up, because:

ClassFoo fc = Foo.class;

compiles, but generates a warning (reference to raw type). But if you 
type this in eclipse:


x fc = Foo.class;

and use eclipse quickfix to change x to the correct type, it'll 
change it to precisely ClassFoo (the JLS is very short about this, 
see also 
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.8.2). 


the faq comes up with this:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ106
and this:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ310


So what the heck is the proper type for the class literal??? I 
couldn't find any!


Finally, note that when you define a method like this:

  static void method1(Foo? extends Bar? y) {
  }

it works like a charm for a new FooSubBarString, i.e., the Foo 
of (anything that extends (bar of anything)) really is the correct 
interpretation.


It's just that the interaction with raw types is completely *foobar* 
(pun intended).


Regards,
Sebastiaan


Happy Weekend,

Martin

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

RE: (Class? extends Page?) casting troubles

2008-06-06 Thread Zappaterrini, Larry

In the example you have detailed, RawBar is not a subtype of Bar?
since it extends the raw type Bar.

-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 11:31 AM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:
 Martin Funk wrote:

 Class? extends Page? means class of (anything that extends
(page of
 anything)).

 I'm not so sure.

 There are 2 separate issues:

 ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
 where RawBar extends Bar as a raw type. That is, given:

   static class FooT {
   }

   static class BarT {
   }

   static class RawBar extends Bar {
   }

   static class SubBarT extends BarT {
   }

 Thus:

Bar? bar = new RawBar(); // works, because RawBar is a subtype of

 Bar?

 But:

Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
THIS 
 IS CAUSING ONE HALF OF ALL OUR HEADACHES

(correction:)
Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK -

THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES

Btw, this does work (like you expect):
Foo? extends Bar? rawbar2 = new FooSubBar?();

 Note that this is the issue that complete baffles me, as RawBar is a 
 subtype of Bar?, so I *really* *really* *REALLY* have no idea why
the 
 compiler chokes on this.

 ISSUE 2: The class literal of a generic type returns a class of a raw 
 type.  Thus Foo.class return ClassFoo. This is also really messed
up, 
 because:

 ClassFoo fc = Foo.class;

 compiles, but generates a warning (reference to raw type). But if you 
 type this in eclipse:

 x fc = Foo.class;

 and use eclipse quickfix to change x to the correct type, it'll 
 change it to precisely ClassFoo (the JLS is very short about this,
see 
 also 

http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
5.8.2). 

 So what the heck is the proper type for the class literal??? I
couldn't 
 find any!

 Finally, note that when you define a method like this:

   static void method1(Foo? extends Bar? y) {
   }

 it works like a charm for a new FooSubBarString, i.e., the Foo of

 (anything that extends (bar of anything)) really is the correct 
 interpretation.

 It's just that the interaction with raw types is completely *foobar* 
 (pun intended).

 Regards,
 Sebastiaan

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

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

Re: (Class? extends Page?) casting troubles


Zappaterrini, Larry wrote:

In the example you have detailed, RawBar is not a subtype of Bar?
since it extends the raw type Bar.


I guess it depends on the definition of subtype. It is at least the case 
that the following assignment compiles without warnings (without 
warnings about unchecked casts):


  Bar? bar = new RawBar();

So is it then a subtype? Or isn't it? It's all terribly inconsistent if 
you ask me. :-(


Regards,
Sebastiaan




-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 11:31 AM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:

Martin Funk wrote:


Class? extends Page? means class of (anything that extends

(page of

anything)).

I'm not so sure.

There are 2 separate issues:

ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
where RawBar extends Bar as a raw type. That is, given:


  static class FooT {
  }

  static class BarT {
  }

  static class RawBar extends Bar {
  }

  static class SubBarT extends BarT {
  }

Thus:

   Bar? bar = new RawBar(); // works, because RawBar is a subtype of



Bar?

But:

   Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
THIS 

IS CAUSING ONE HALF OF ALL OUR HEADACHES


(correction:)
Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK -

THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES

Btw, this does work (like you expect):
Foo? extends Bar? rawbar2 = new FooSubBar?();

Note that this is the issue that complete baffles me, as RawBar is a 
subtype of Bar?, so I *really* *really* *REALLY* have no idea why
the 

compiler chokes on this.

ISSUE 2: The class literal of a generic type returns a class of a raw 
type.  Thus Foo.class return ClassFoo. This is also really messed
up, 

because:

ClassFoo fc = Foo.class;


compiles, but generates a warning (reference to raw type). But if you 
type this in eclipse:


x fc = Foo.class;

and use eclipse quickfix to change x to the correct type, it'll 
change it to precisely ClassFoo (the JLS is very short about this,
see 
also 


http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
5.8.2). 


So what the heck is the proper type for the class literal??? I
couldn't 

find any!

Finally, note that when you define a method like this:

  static void method1(Foo? extends Bar? y) {
  }

it works like a charm for a new FooSubBarString, i.e., the Foo of


(anything that extends (bar of anything)) really is the correct 
interpretation.


It's just that the interaction with raw types is completely *foobar* 
(pun intended).


Regards,
Sebastiaan









__

The information contained in this message is proprietary and/or confidential. If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, 
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, 
please be aware that any message addressed to our domain is subject to archiving and review by 
persons other than the intended recipient. Thank you.

_

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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles


Martin Funk wrote:
   Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK 
- THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES


Btw, this does work (like you expect):
   Foo? extends Bar? rawbar2 = new FooSubBar?();

maybe some more wisdom can be found here:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ209 

In her words it would mean 'raw types are not part of the type family 
denoted by the wildcard parametrized type Bar?'
But I'm still puzzled, since taking that FAQ it doesn't explain why in 
the case of the generic method


public T extends Component? void dol(ClassT clazz)

the raw types are all of a sudden member of that family


Nor does it explain why assignment:

  Bar? bar = new RawBar();

works, without errors or warnings...


the faq comes up with this:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ106 


and this:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ310 


I find the argumentation rather mind-bending. And I still wonder how you 
can rationalize away that Foo.class returns a type that generates 
warnings if you  want to use it!


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature

RE: (Class? extends Page?) casting troubles

2008-06-06 Thread Zappaterrini, Larry

Sorry, I should have been more clear about subtype. :) When dealing with
raw types, the raw type is considered a super type of the generic type.
So Bar is a super type of Bar?. Since RawType extends the raw type
Bar, consider it to be a peer of Bar?. When you consider them as
peers, a warning is warranted. The new example you use works due to
erasure. Bar? as declared in source code becomes Bar in byte code. So
the statement becomes:

Bar bar = new RawBar();

Which is perfectly legal. I have found that most of perceived
inconsistencies in Java generics stems  from erasure and sub type
substitution. The golden rule of generics is that the byte code produced
by compiling generics will never produce an invalid cast so long as the
code does not produce any warnings. This causes some things that may
seem intuitive to be illegal.
 
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 4:16 PM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

Zappaterrini, Larry wrote:
 In the example you have detailed, RawBar is not a subtype of Bar?
 since it extends the raw type Bar.

I guess it depends on the definition of subtype. It is at least the case

that the following assignment compiles without warnings (without 
warnings about unchecked casts):

   Bar? bar = new RawBar();

So is it then a subtype? Or isn't it? It's all terribly inconsistent if 
you ask me. :-(

Regards,
Sebastiaan



 -Original Message-
 From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
 Sent: Friday, June 06, 2008 11:31 AM
 To: users@wicket.apache.org
 Subject: Re: (Class? extends Page?) casting troubles
 
 ARgh, you always make typos with this stuff.
 
 See correction.
 
 Sebastiaan van Erk wrote:
 Martin Funk wrote:

 Class? extends Page? means class of (anything that extends
 (page of
 anything)).
 I'm not so sure.
 There are 2 separate issues:

 ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
 where RawBar extends Bar as a raw type. That is, given:

   static class FooT {
   }

   static class BarT {
   }

   static class RawBar extends Bar {
   }

   static class SubBarT extends BarT {
   }

 Thus:

Bar? bar = new RawBar(); // works, because RawBar is a subtype
of
 
 Bar?

 But:

Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
 THIS 
 IS CAUSING ONE HALF OF ALL OUR HEADACHES
 
 (correction:)
 Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK
-
 
 THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES
 
 Btw, this does work (like you expect):
 Foo? extends Bar? rawbar2 = new FooSubBar?();
 
 Note that this is the issue that complete baffles me, as RawBar is a 
 subtype of Bar?, so I *really* *really* *REALLY* have no idea why
 the 
 compiler chokes on this.

 ISSUE 2: The class literal of a generic type returns a class of a raw

 type.  Thus Foo.class return ClassFoo. This is also really messed
 up, 
 because:
 
 ClassFoo fc = Foo.class;

 compiles, but generates a warning (reference to raw type). But if you

 type this in eclipse:

 x fc = Foo.class;

 and use eclipse quickfix to change x to the correct type, it'll 
 change it to precisely ClassFoo (the JLS is very short about this,
 see 
 also 


http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
 5.8.2). 

 So what the heck is the proper type for the class literal??? I
 couldn't 
 find any!

 Finally, note that when you define a method like this:

   static void method1(Foo? extends Bar? y) {
   }

 it works like a charm for a new FooSubBarString, i.e., the Foo
of
 
 (anything that extends (bar of anything)) really is the correct 
 interpretation.

 It's just that the interaction with raw types is completely *foobar* 
 (pun intended).

 Regards,
 Sebastiaan







 
 __
 
 The information contained in this message is proprietary and/or
confidential. If you are not the 
 intended recipient, please: (i) delete the message and all copies;
(ii) do not disclose, 
 distribute or use the message in any manner; and (iii) notify the
sender immediately. In addition, 
 please be aware that any message addressed to our domain is subject to
archiving and review by 
 persons other than the intended recipient. Thank you.
 _
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you

RE: (Class? extends Page?) casting troubles

2008-06-05 Thread Rod Good

Thanks Peter (and Martin and Larry). 

My issue was specifically with overriding 

Class? extends Page? getHomePage() 

from the Application class, when extending AuthenticatedWebApplication. 

It looks the same as the problem below, but not quite... 

Is there an idiom for overriding getHomePage() in Wicket 1.4 ? I'm
getting around it with a shocking cast, I'm sure others have run into
the same problem.

-Original Message-
From: Peter Ertl [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 4 June 2008 6:32 PM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

I remember that having more than one wildcard in an type expression
seems to be inherently broken.

Usually you can rewrite something like

   void foo(Class? extends Page? pageClass)

into something like

   X extends Page? void foo(ClassX pageClass)

I would bet this solves your problem :-)

However, nobody can explain why... :-(

Probably some lack of the generics specification, broken compiler, or
whatever...

I would suggest to avoid more than one wildcard in one type expression
in general and use above workaround.

Cheers
Peter


Am 04.06.2008 um 10:10 schrieb Johan Compagner:

 Yeah it is very strange that you get different errors in eclipse and 
 javac.
 I wonder which one is correcct..

 But you have to generify the Page then it should work fine (like
 Void)

 I think we just need to drop the ? in that example What do you 
 exactly call?


 johan


 On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED]
 wrote:

 Hi,

 I'm getting inconvertible type errors when I compile from Maven on 
 the command line with Java 6.

 Does anyone know if this issue was resolved ? I am building against
 1.4-m2 - downloaded today (04-06-2008).

 The issue is the same as noted by Ryan Mckinley on 05/21/2008 :


 strangely, things work fine for me in eclipse, but from the command
 line, I still get:

 $ mvn clean install:


 /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/
 website/
 wicket/page/DownloadingPage.java:[18,97] inconvertible types found :
 java.lang.Classdexter.website.wicket.page.account.DexSignInPage
 required: java.lang.Class? extends org.apache.wicket.Page?

 I ran: mvn clean install in the wicket directory...

 Not sure if the java version is helpful: ryan$ mvn -version Maven
 version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp

 Thanks,
 Rod.

 NOTICE
 This e-mail and any attachments are confidential and may contain 
 copyright material of Macquarie Group Limited or third parties. If 
 you are not the intended recipient of this email you should not read,

 print, re- transmit, store or act in reliance on this e-mail or any 
 attachments, and should destroy all copies of them. Macquarie Group 
 Limited does not guarantee the integrity of any emails or any 
 attached files. The views or opinions expressed are the author's own 
 and may not reflect the views or opinions of Macquarie Group Limited.




-
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: (Class? extends Page?) casting troubles

2008-06-05 Thread Jeremy Thomerson

I haven't read the whole thread, but you should be fine as long as your
returned page class uses generics...

Here's what I use in one app, no warnings, no casts:

@Override
public Class? extends Page? getHomePage() {
return Home.class;
}


public class Home extends WebPageVoid {
}

-- 
Jeremy Thomerson
http://www.wickettraining.com

On Thu, Jun 5, 2008 at 9:05 PM, Rod Good [EMAIL PROTECTED] wrote:

 Thanks Peter (and Martin and Larry).

 My issue was specifically with overriding

 Class? extends Page? getHomePage()

 from the Application class, when extending AuthenticatedWebApplication.

 It looks the same as the problem below, but not quite...

 Is there an idiom for overriding getHomePage() in Wicket 1.4 ? I'm
 getting around it with a shocking cast, I'm sure others have run into
 the same problem.

 -Original Message-
 From: Peter Ertl [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, 4 June 2008 6:32 PM
 To: users@wicket.apache.org
 Subject: Re: (Class? extends Page?) casting troubles

 I remember that having more than one wildcard in an type expression
 seems to be inherently broken.

 Usually you can rewrite something like

   void foo(Class? extends Page? pageClass)

 into something like

   X extends Page? void foo(ClassX pageClass)

 I would bet this solves your problem :-)

 However, nobody can explain why... :-(

 Probably some lack of the generics specification, broken compiler, or
 whatever...

 I would suggest to avoid more than one wildcard in one type expression
 in general and use above workaround.

 Cheers
 Peter


 Am 04.06.2008 um 10:10 schrieb Johan Compagner:

  Yeah it is very strange that you get different errors in eclipse and
  javac.
  I wonder which one is correcct..
 
  But you have to generify the Page then it should work fine (like
  Void)
 
  I think we just need to drop the ? in that example What do you
  exactly call?
 
 
  johan
 
 
  On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED]
  wrote:
 
  Hi,
 
  I'm getting inconvertible type errors when I compile from Maven on
  the command line with Java 6.
 
  Does anyone know if this issue was resolved ? I am building against
  1.4-m2 - downloaded today (04-06-2008).
 
  The issue is the same as noted by Ryan Mckinley on 05/21/2008 :
 
 
  strangely, things work fine for me in eclipse, but from the command
  line, I still get:
 
  $ mvn clean install:
 
 
  /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/
  website/
  wicket/page/DownloadingPage.java:[18,97] inconvertible types found :
  java.lang.Classdexter.website.wicket.page.account.DexSignInPage
  required: java.lang.Class? extends org.apache.wicket.Page?
 
  I ran: mvn clean install in the wicket directory...
 
  Not sure if the java version is helpful: ryan$ mvn -version Maven
  version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp
 
  Thanks,
  Rod.
 
  NOTICE
  This e-mail and any attachments are confidential and may contain
  copyright material of Macquarie Group Limited or third parties. If
  you are not the intended recipient of this email you should not read,

  print, re- transmit, store or act in reliance on this e-mail or any
  attachments, and should destroy all copies of them. Macquarie Group
  Limited does not guarantee the integrity of any emails or any
  attached files. The views or opinions expressed are the author's own
  and may not reflect the views or opinions of Macquarie Group Limited.
 
 


 -
 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: (Class? extends Page?) casting troubles

2008-06-05 Thread Rod Good

Thanks Jeremy, that definitely looks like the problem. 

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Friday, 6 June 2008 1:01 PM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

I haven't read the whole thread, but you should be fine as long as your
returned page class uses generics...

Here's what I use in one app, no warnings, no casts:

@Override
public Class? extends Page? getHomePage() {
return Home.class;
}

public class Home extends WebPageVoid { }

--
Jeremy Thomerson
http://www.wickettraining.com

On Thu, Jun 5, 2008 at 9:05 PM, Rod Good [EMAIL PROTECTED] wrote:

 Thanks Peter (and Martin and Larry).

 My issue was specifically with overriding

 Class? extends Page? getHomePage()

 from the Application class, when extending
AuthenticatedWebApplication.

 It looks the same as the problem below, but not quite...

 Is there an idiom for overriding getHomePage() in Wicket 1.4 ? I'm 
 getting around it with a shocking cast, I'm sure others have run into 
 the same problem.

 -Original Message-
 From: Peter Ertl [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, 4 June 2008 6:32 PM
 To: users@wicket.apache.org
 Subject: Re: (Class? extends Page?) casting troubles

 I remember that having more than one wildcard in an type expression 
 seems to be inherently broken.

 Usually you can rewrite something like

   void foo(Class? extends Page? pageClass)

 into something like

   X extends Page? void foo(ClassX pageClass)

 I would bet this solves your problem :-)

 However, nobody can explain why... :-(

 Probably some lack of the generics specification, broken compiler, or 
 whatever...

 I would suggest to avoid more than one wildcard in one type expression

 in general and use above workaround.

 Cheers
 Peter

 Am 04.06.2008 um 10:10 schrieb Johan Compagner:

  Yeah it is very strange that you get different errors in eclipse and

  javac.
  I wonder which one is correcct..

  But you have to generify the Page then it should work fine (like
  Void)

  I think we just need to drop the ? in that example What do you 
  exactly call?

  johan

  On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED]
  wrote:

  Hi,

  I'm getting inconvertible type errors when I compile from Maven on 
  the command line with Java 6.

  Does anyone know if this issue was resolved ? I am building against
  1.4-m2 - downloaded today (04-06-2008).

  The issue is the same as noted by Ryan Mckinley on 05/21/2008 :

  strangely, things work fine for me in eclipse, but from the 
  command
  line, I still get:

  $ mvn clean install:

  /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/
  website/
  wicket/page/DownloadingPage.java:[18,97] inconvertible types found
:
  java.lang.Classdexter.website.wicket.page.account.DexSignInPage
  required: java.lang.Class? extends org.apache.wicket.Page?

  I ran: mvn clean install in the wicket directory...

  Not sure if the java version is helpful: ryan$ mvn -version Maven
  version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp

  Thanks,
  Rod.

  NOTICE
  This e-mail and any attachments are confidential and may contain 
  copyright material of Macquarie Group Limited or third parties. If 
  you are not the intended recipient of this email you should not 
  read,

  print, re- transmit, store or act in reliance on this e-mail or any

  attachments, and should destroy all copies of them. Macquarie Group

  Limited does not guarantee the integrity of any emails or any 
  attached files. The views or opinions expressed are the author's 
  own and may not reflect the views or opinions of Macquarie Group
Limited.

 -
 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: (Class? extends Page?) casting troubles

2008-06-04 Thread Rod Good

Hi,
 
I'm getting inconvertible type errors when I compile from Maven on the
command line with Java 6.
 
Does anyone know if this issue was resolved ? I am building against
1.4-m2 - downloaded today (04-06-2008).
 
The issue is the same as noted by Ryan Mckinley on 05/21/2008 :
 
 
 strangely, things work fine for me in eclipse, but from the command
line, I still get:
 
 $ mvn clean install:
 

/Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/
wicket/page/DownloadingPage.java:[18,97] inconvertible types found :
java.lang.Classdexter.website.wicket.page.account.DexSignInPage
required: java.lang.Class? extends org.apache.wicket.Page?
 
 I ran: mvn clean install in the wicket directory...
 
 Not sure if the java version is helpful: ryan$ mvn -version Maven
version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp 
 
Thanks,
Rod.

NOTICE
This e-mail and any attachments are confidential and may contain copyright 
material of Macquarie Group Limited or third parties. If you are not the 
intended recipient of this email you should not read, print, re-transmit, store 
or act in reliance on this e-mail or any attachments, and should destroy all 
copies of them. Macquarie Group Limited does not guarantee the integrity of any 
emails or any attached files. The views or opinions expressed are the author's 
own and may not reflect the views or opinions of Macquarie Group Limited.

Re: (Class? extends Page?) casting troubles

2008-06-04 Thread Johan Compagner

Yeah it is very strange that you get different errors in eclipse and javac.
I wonder which one is correcct..

But you have to generify the Page then it should work fine (like Void)

I think we just need to drop the ? in that example
What do you exactly call?


johan


On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED] wrote:

 Hi,

 I'm getting inconvertible type errors when I compile from Maven on the
 command line with Java 6.

 Does anyone know if this issue was resolved ? I am building against
 1.4-m2 - downloaded today (04-06-2008).

 The issue is the same as noted by Ryan Mckinley on 05/21/2008 :

 
  strangely, things work fine for me in eclipse, but from the command
 line, I still get:
 
  $ mvn clean install:
 
 
 /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/
 wicket/page/DownloadingPage.java:[18,97] inconvertible types found :
 java.lang.Classdexter.website.wicket.page.account.DexSignInPage
 required: java.lang.Class? extends org.apache.wicket.Page?
 
  I ran: mvn clean install in the wicket directory...
 
  Not sure if the java version is helpful: ryan$ mvn -version Maven
 version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp

 Thanks,
 Rod.

 NOTICE
 This e-mail and any attachments are confidential and may contain copyright
 material of Macquarie Group Limited or third parties. If you are not the
 intended recipient of this email you should not read, print, re-transmit,
 store or act in reliance on this e-mail or any attachments, and should
 destroy all copies of them. Macquarie Group Limited does not guarantee the
 integrity of any emails or any attached files. The views or opinions
 expressed are the author's own and may not reflect the views or opinions of
 Macquarie Group Limited.

Re: (Class? extends Page?) casting troubles

2008-06-04 Thread Peter Ertl

I remember that having more than one wildcard in an type expression  
seems to be inherently broken.


Usually you can rewrite something like

  void foo(Class? extends Page? pageClass)

into something like

  X extends Page? void foo(ClassX pageClass)

I would bet this solves your problem :-)

However, nobody can explain why... :-(

Probably some lack of the generics specification, broken compiler, or  
whatever...


I would suggest to avoid more than one wildcard in one type expression  
in general and use above workaround.


Cheers
Peter


Am 04.06.2008 um 10:10 schrieb Johan Compagner:

Yeah it is very strange that you get different errors in eclipse and  
javac.

I wonder which one is correcct..

But you have to generify the Page then it should work fine (like  
Void)


I think we just need to drop the ? in that example
What do you exactly call?


johan


On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED]  
wrote:



Hi,

I'm getting inconvertible type errors when I compile from Maven on  
the

command line with Java 6.

Does anyone know if this issue was resolved ? I am building against
1.4-m2 - downloaded today (04-06-2008).

The issue is the same as noted by Ryan Mckinley on 05/21/2008 :



strangely, things work fine for me in eclipse, but from the command

line, I still get:


$ mvn clean install:


/Users/ryan/Documents/workspace/dexter/website/src/java/dexter/ 
website/

wicket/page/DownloadingPage.java:[18,97] inconvertible types found :
java.lang.Classdexter.website.wicket.page.account.DexSignInPage
required: java.lang.Class? extends org.apache.wicket.Page?


I ran: mvn clean install in the wicket directory...

Not sure if the java version is helpful: ryan$ mvn -version Maven

version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp

Thanks,
Rod.

NOTICE
This e-mail and any attachments are confidential and may contain  
copyright
material of Macquarie Group Limited or third parties. If you are  
not the
intended recipient of this email you should not read, print, re- 
transmit,
store or act in reliance on this e-mail or any attachments, and  
should
destroy all copies of them. Macquarie Group Limited does not  
guarantee the

integrity of any emails or any attached files. The views or opinions
expressed are the author's own and may not reflect the views or  
opinions of

Macquarie Group Limited.





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

Re: (Class? extends Page?) casting troubles

2008-06-04 Thread Martin Funk

Hi Peter,

2008/6/4 Peter Ertl [EMAIL PROTECTED]:

 I remember that having more than one wildcard in an type expression seems
 to be inherently broken.

I hope it is not, I hope it is just hard to understand.



 Usually you can rewrite something like

  void foo(Class? extends Page? pageClass)

I think both signatures are not semanticall equal. Here there are two
wildcards. On one hand wildcards are by definition independent from each
other, but on the other hand there are coupled in this example, by the
extends. Maybe in java it was decided that the independance is more
important than the coupling.
As I read the signature the type parameter might be of any type as long as
it extends Page parametrized with any other type.
Now when the method is used one parameter is given.
foo(Bar.class)
If Bar is a non-generic subtype of Page the compiler is happy. Either cause
the type paramter of Page is well defined by the declaration of Bar or the
compiler just forgets about them type parameters in an non-generic case (I
don't know).
If Bar is a generic subtype than Bar.class is its raw type which is a
subtype of the raw type of Page, but nothing else.
So the compiler is not happy.



 into something like

  X extends Page? void foo(ClassX pageClass)

Having the wildcard in the generic type definition of the method it relaxes
the Bounds.
Here the compiler just has to make sure that X extends a parametrized Page
which every subtype of Page does.

@All
Is there anyone out there having a better explanation? Currently I'm working
my way through the generics FAQ by Angelika Langer
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
I see quite some statements there that apply here, but I still can't grab
the whole picture.



 I would bet this solves your problem :-)

 However, nobody can explain why... :-(

 Probably some lack of the generics specification, broken compiler, or
 whatever...

 I would suggest to avoid more than one wildcard in one type expression in
 general and use above workaround.

I'm not sure about the analysis but still a good guideline.


mf














 Cheers
 Peter


 Am 04.06.2008 um 10:10 schrieb Johan Compagner:


  Yeah it is very strange that you get different errors in eclipse and
 javac.
 I wonder which one is correcct..

 But you have to generify the Page then it should work fine (like Void)

 I think we just need to drop the ? in that example
 What do you exactly call?


 johan


 On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED] wrote:

  Hi,

 I'm getting inconvertible type errors when I compile from Maven on the
 command line with Java 6.

 Does anyone know if this issue was resolved ? I am building against
 1.4-m2 - downloaded today (04-06-2008).

 The issue is the same as noted by Ryan Mckinley on 05/21/2008 :


 strangely, things work fine for me in eclipse, but from the command

 line, I still get:


 $ mvn clean install:


  /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/
 wicket/page/DownloadingPage.java:[18,97] inconvertible types found :
 java.lang.Classdexter.website.wicket.page.account.DexSignInPage
 required: java.lang.Class? extends org.apache.wicket.Page?


 I ran: mvn clean install in the wicket directory...

 Not sure if the java version is helpful: ryan$ mvn -version Maven

 version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp

 Thanks,
 Rod.

 NOTICE
 This e-mail and any attachments are confidential and may contain
 copyright
 material of Macquarie Group Limited or third parties. If you are not the
 intended recipient of this email you should not read, print, re-transmit,
 store or act in reliance on this e-mail or any attachments, and should
 destroy all copies of them. Macquarie Group Limited does not guarantee
 the
 integrity of any emails or any attached files. The views or opinions
 expressed are the author's own and may not reflect the views or opinions
 of
 Macquarie Group Limited.




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

RE: (Class? extends Page?) casting troubles

2008-06-04 Thread Zappaterrini, Larry

This is my take on it:

http://www.nabble.com/RE%3A-%28Class%3C--extends-Page%3C-%3E%3E%29-casti
ng-troubles-p17370699.html

I feel it covers the topic pretty thoroughly but I am by no means an
expert on the matter.
 
-Original Message-
From: Martin Funk [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 04, 2008 8:14 AM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

Hi Peter,

2008/6/4 Peter Ertl [EMAIL PROTECTED]:

 I remember that having more than one wildcard in an type expression
seems
 to be inherently broken.

I hope it is not, I hope it is just hard to understand.



 Usually you can rewrite something like

  void foo(Class? extends Page? pageClass)

I think both signatures are not semanticall equal. Here there are two
wildcards. On one hand wildcards are by definition independent from each
other, but on the other hand there are coupled in this example, by the
extends. Maybe in java it was decided that the independance is more
important than the coupling.
As I read the signature the type parameter might be of any type as long
as
it extends Page parametrized with any other type.
Now when the method is used one parameter is given.
foo(Bar.class)
If Bar is a non-generic subtype of Page the compiler is happy. Either
cause
the type paramter of Page is well defined by the declaration of Bar or
the
compiler just forgets about them type parameters in an non-generic case
(I
don't know).
If Bar is a generic subtype than Bar.class is its raw type which is a
subtype of the raw type of Page, but nothing else.
So the compiler is not happy.



 into something like

  X extends Page? void foo(ClassX pageClass)

Having the wildcard in the generic type definition of the method it
relaxes
the Bounds.
Here the compiler just has to make sure that X extends a parametrized
Page
which every subtype of Page does.

@All
Is there anyone out there having a better explanation? Currently I'm
working
my way through the generics FAQ by Angelika Langer
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
I see quite some statements there that apply here, but I still can't
grab
the whole picture.



 I would bet this solves your problem :-)

 However, nobody can explain why... :-(

 Probably some lack of the generics specification, broken compiler, or
 whatever...

 I would suggest to avoid more than one wildcard in one type expression
in
 general and use above workaround.

I'm not sure about the analysis but still a good guideline.


mf














 Cheers
 Peter


 Am 04.06.2008 um 10:10 schrieb Johan Compagner:


  Yeah it is very strange that you get different errors in eclipse and
 javac.
 I wonder which one is correcct..

 But you have to generify the Page then it should work fine (like
Void)

 I think we just need to drop the ? in that example
 What do you exactly call?


 johan


 On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED]
wrote:

  Hi,

 I'm getting inconvertible type errors when I compile from Maven on
the
 command line with Java 6.

 Does anyone know if this issue was resolved ? I am building against
 1.4-m2 - downloaded today (04-06-2008).

 The issue is the same as noted by Ryan Mckinley on 05/21/2008 :


 strangely, things work fine for me in eclipse, but from the command

 line, I still get:


 $ mvn clean install:



/Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/
 wicket/page/DownloadingPage.java:[18,97] inconvertible types found :
 java.lang.Classdexter.website.wicket.page.account.DexSignInPage
 required: java.lang.Class? extends org.apache.wicket.Page?


 I ran: mvn clean install in the wicket directory...

 Not sure if the java version is helpful: ryan$ mvn -version Maven

 version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp

 Thanks,
 Rod.

 NOTICE
 This e-mail and any attachments are confidential and may contain
 copyright
 material of Macquarie Group Limited or third parties. If you are not
the
 intended recipient of this email you should not read, print,
re-transmit,
 store or act in reliance on this e-mail or any attachments, and
should
 destroy all copies of them. Macquarie Group Limited does not
guarantee
 the
 integrity of any emails or any attached files. The views or opinions
 expressed are the author's own and may not reflect the views or
opinions
 of
 Macquarie Group Limited.




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



__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you

Re: (Class? extends Page?) casting troubles

2008-05-25 Thread Gwyn Evans

Yes, that's fine as long as you're aware of the GenericLink
alternative, but if you're not, then when you auto-complete
L[i[n[k]]], if you use LinkGeneric, it'll show up whereas if
GenericLink, it won't.

/Gwyn

On Sat, May 24, 2008 at 9:51 PM, Matej Knopp [EMAIL PROTECTED] wrote:
 I don't buy the autocompletion as argument. Not with eclipse. It might
 be difference when you do it first time and don't know the classes,
 but every other time you just write GLink and eclipse autocompletes it
 just fine.

 -Matej

 On Sat, May 24, 2008 at 3:17 PM, Gwyn Evans [EMAIL PROTECTED] wrote:
 On Sat, May 24, 2008 at 11:42 AM, John Patterson [EMAIL PROTECTED] wrote:

 The reason I put LinkGeneric rather than GenericLink was simply so that the
 two options would appear next to each other in code completions.  But of
 course in English GenericLink is more correct.

 Good point regarding completions.  Anyway, flexible, english is!  Hmm.

 /Gwyn
 - http://www.yodaspeak.co.uk

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

RE: (Class? extends Page?) casting troubles

2008-05-25 Thread Hoover, William

+1

This seems to be the best option so far. It's confusing to see a bunch
of subclasses whose only purpose is to avoid generic type definitions. A
separate dependency makes sense. If anyone is that concerned with having
to define void generic types they can add the dependency.

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 24, 2008 10:51 AM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

thats funny, my primary usecase is to use link WITH a model. so why dont
we keep Link generified and have a subclass VoidLink.

i am also not a big fan of using class hierarchy essentially as a
typedef, seems like a nasty hack to me (which i am willing to live
with). perhaps we can have wicket-void module that can contain all these
Void subclasses.

-igor

On Sat, May 24, 2008 at 2:24 AM, Johan Compagner [EMAIL PROTECTED]
wrote:
 +1

 On Sat, May 24, 2008 at 8:09 AM, Daniel Walmsley [EMAIL PROTECTED]
wrote:

 Just to quickly weigh in on the verbosity argument:
 As someone who has coded Java (and Perl, C++, etc) in every 
 environment from individual projects to multinational finance 
 systems, I will say that verbosity of code runs a far, far, distant
third (or twentieth) to:
 1. Readability/Understandability, and 2. Maintainability By 
 illustrating succinctly what type of model (if any) a component will 
 contain, generics in Wicket neatly accomplish point 1.
 By allowing your IDE to tell you when you're setting the wrong type 
 of model object in a component it neatly accomplishes point 2.
 You write your code once. You maintain it thousands of times. The 
 trade-off to me is perfectly clear, and this will be vindicated when 
 Wicket-based enterprise projects start conspicuously succeeding where

 others have failed.
 Also, don't mistake verbosity for DRY-ness. COBOL was verbose 
 because it forced you to repeat yourself over and over. Java supports

 very elegant reuse, so each piece of functionality is written just 
 once. Thanks to Annotations we've cut down (significantly) on 
 boilerplate, and the whole appeal of Wicket is its ability to enable 
 reuse at the web tier. Between generics, annotations and component 
 reuse, this makes Wicket a very DRY-friendly framework, and has 
 vastly reduced the amount of code I've had to cut for my clients.
 I've used every framework under the sun (no pun intended) and Wicket 
 rules over them all.
 Cheers,
 Dan
 On 22/05/2008, at 07:20AM, Jonathan Locke wrote:

 I'm jumping into this conversation very late and I simply can't catch

 up on this entire thread, but isn't it possible to have a non-generic

 build of the generic framework for people that don't want to use 
 generics?

 Skimming this discussion, in general, I tend to agree with Eelco. A 
 good general approach would be to fully generify the framework and 
 then vote to back out the things which are really not helpful (for 
 example, although page is technically a component, pages often have 
 no models, so it might be a good thing to a un-generify). Once we 
 have found a practical/optimal level of generification should we vote

 on it. Let's not throw the baby out with the bathwater.

 Also, for myself, I disagree that type safety is not a primary goal 
 of generics. Even if the API were completely clear already, I'd still

 prefer more type safety.


 Martijn Dashorst wrote:

 On Wed, May 21, 2008 at 5:05 PM, Johan Compagner 
 [EMAIL PROTECTED]

 wrote:

 Generics is type safety

 I didn't say generics isn't type safety. But APPLYING generics for 
 the

 Wicket framework API *ISN'T* its primary goal. API clarity *IS*. Less

 questions on the mailing list regarding DDC, ListView, etc. is the

 main goal for applying generics in Wicket.

 I am against this abuse big time -1000 from me

 I'm -1000^1 for abusing my eyes and brain in

 the way it currently is implemented in Wicket. It is completely and

 utterly unusable for beginners. There is no way this is going to make

 the number of questions on the mailinglist less (other than by 
 scaring

 away anyone that wants to actually use the framework)

 Martijn

 -

 To unsubscribe, e-mail: [EMAIL PROTECTED]

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




 --
 View this message in context:
 http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting
 -troubles-tp17355847p17375350.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]


 Daniel Walmsley
 Director, Firesyde
 e: [EMAIL PROTECTED]
 m: +61404864141




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

Re: (Class? extends Page?) casting troubles

2008-05-25 Thread Matej Knopp

I'm pretty sure it's not that difficult to look at the class hierarchy
given that Link would extend GenericLink. I don't think this justifies
the name, LinkGeneric just sounds too weird to me.

-Matej

On Sun, May 25, 2008 at 12:39 PM, Gwyn Evans [EMAIL PROTECTED] wrote:
 Yes, that's fine as long as you're aware of the GenericLink
 alternative, but if you're not, then when you auto-complete
 L[i[n[k]]], if you use LinkGeneric, it'll show up whereas if
 GenericLink, it won't.

 /Gwyn

 On Sat, May 24, 2008 at 9:51 PM, Matej Knopp [EMAIL PROTECTED] wrote:
 I don't buy the autocompletion as argument. Not with eclipse. It might
 be difference when you do it first time and don't know the classes,
 but every other time you just write GLink and eclipse autocompletes it
 just fine.

 -Matej

 On Sat, May 24, 2008 at 3:17 PM, Gwyn Evans [EMAIL PROTECTED] wrote:
 On Sat, May 24, 2008 at 11:42 AM, John Patterson [EMAIL PROTECTED] wrote:

 The reason I put LinkGeneric rather than GenericLink was simply so that the
 two options would appear next to each other in code completions.  But of
 course in English GenericLink is more correct.

 Good point regarding completions.  Anyway, flexible, english is!  Hmm.

 /Gwyn
 - http://www.yodaspeak.co.uk

 -
 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: (Class? extends Page?) casting troubles

2008-05-25 Thread John Patterson




Matej Knopp-2 wrote:
 
 I don't buy the autocompletion as argument. 
 

Yeah it is a bit crap.
-- 
View this message in context: 
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17459443.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: (Class? extends Page?) casting troubles

2008-05-24 Thread Daniel Walmsley

Just to quickly weigh in on the verbosity argument:As someone who has coded Java (and Perl, C++, etc) in every environment from individual projects to multinational finance systems, I will say that verbosity of code runs a far, far, distant third (or twentieth) to:1. Readability/Understandability, and2. MaintainabilityBy illustrating succinctly what type of model (if any) a component will contain, generics in Wicket neatly accomplish point 1.By allowing your IDE to tell you when you're setting the wrong type of model object in a component it neatly accomplishes point 2.You write your code once. You maintain it thousands of times. The trade-off to me is perfectly clear, and this will be vindicated when Wicket-based enterprise projects start conspicuously succeeding where others have failed.Also, don't mistake "verbosity" for "DRY-ness". COBOL was verbose because it forced you to repeat yourself over and over. Java supports very elegant reuse, so each piece of functionality is written just once. Thanks to Annotations we've cut down (significantly) on boilerplate, and the whole appeal of Wicket is its ability to enable reuse at the web tier. Between generics, annotations and component reuse, this makes Wicket a very DRY-friendly framework, and has vastly reduced the amount of code I've had to cut for my clients.I've used every framework under the sun (no pun intended) and Wicket rules over them all.Cheers,DanOn 22/05/2008, at 07:20AM, Jonathan Locke wrote:I'm jumping into this conversation very late and I simply can't catch up onthis entire thread, but isn't it possible to have a non-generic build of thegeneric framework for people that don't want to use generics?Skimming this discussion, in general, I tend to agree with Eelco. A goodgeneral approach would be to fully generify the framework and then vote toback out the things which are really not helpful (for example, although pageis technically a component, pages often have no models, so it might be agood thing to a un-generify). Once we have found a practical/optimal levelof generification should we vote on it. Let's not throw the baby out withthe bathwater.Also, for myself, I disagree that type safety is not a primary goal ofgenerics. Even if the API were completely clear already, I'd still prefermore type safety.Martijn Dashorst wrote:On Wed, May 21, 2008 at 5:05 PM, Johan Compagner [EMAIL PROTECTED]>wrote:Generics is type safetyI didn't say generics isn't type safety. But APPLYING generics for theWicket framework API *ISN'T* its primary goal. API clarity *IS*. Lessquestions on the mailing list regarding DDC, ListView, etc. is themain goal for applying generics in Wicket.I am against this abuse big time -1000 from meI'm -1000^1 for abusing my eyes and brain inthe way it currently is implemented in Wicket. It is completely andutterly unusable for beginners. There is no way this is going to makethe number of questions on the mailinglist less (other than by scaringaway anyone that wants to actually use the framework)Martijn-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]-- View this message in context: http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17375350.htmlSent from the Wicket - User mailing list archive at Nabble.com.-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED] Daniel WalmsleyDirector,Firesydee:[EMAIL PROTECTED]m: +61404864141

Re: (Class? extends Page?) casting troubles

2008-05-24 Thread John Patterson




Jonathan Locke wrote:
 
 Personally, I don't see this use of Void as something even remotely close
 to a reason to scrap it. I would happily use that construct every day. But
 that's just me.
 

I completely agree with this and have found that specifying Void actually
makes me a lot more conscious about the roll of the model.  I find it
invaluable to have Eclipse quickfix assign to local variable automatically
with the correct type from getModelObject().  Would be a terrible shame to
lose this.

Scrapping it on a case by case basis seems to make the most sense.  Is Link
one of these cases?  It is *normally* used without a model.  For such common
cases it is easy to create a non-generic subclass.  What is the problem with
that?

Is it possible to use a generic base class for users that want to have a
type safe model like:

class Link extends LinkGenericVoid
{
}

LinkGenericT
{
}

The generic base class could be used in core components.

John
-- 
View this message in context: 
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17446015.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: (Class? extends Page?) casting troubles

2008-05-24 Thread Johan Compagner

On Sat, May 24, 2008 at 8:09 AM, Daniel Walmsley [EMAIL PROTECTED] wrote:

Just to quickly weigh in on the verbosity argument:

As someone who has coded Java (and Perl, C++, etc) in every environment
from individual projects to multinational finance systems, I will say that
verbosity of code runs a far, far, distant third (or twentieth) to:

1. Readability/Understandability, and
2. Maintainability

By illustrating succinctly what type of model (if any) a component will
contain, generics in Wicket neatly accomplish point 1.

By allowing your IDE to tell you when you're setting the wrong type of
model object in a component it neatly accomplishes point 2.

You write your code once. You maintain it thousands of times. The trade-off
to me is perfectly clear, and this will be vindicated when Wicket-based
enterprise projects start conspicuously succeeding where others have failed.

Also, don't mistake verbosity for DRY-ness. COBOL was verbose because
it forced you to repeat yourself over and over. Java supports very elegant
reuse, so each piece of functionality is written just once. Thanks to
Annotations we've cut down (significantly) on boilerplate, and the whole
appeal of Wicket is its ability to enable reuse at the web tier. Between
generics, annotations and component reuse, this makes Wicket a very
DRY-friendly framework, and has vastly reduced the amount of code I've had
to cut for my clients.

I've used every framework under the sun (no pun intended) and Wicket rules
over them all.

Cheers,
Dan

On 22/05/2008, at 07:20AM, Jonathan Locke wrote:

I'm jumping into this conversation very late and I simply can't catch up on
this entire thread, but isn't it possible to have a non-generic build of
the
generic framework for people that don't want to use generics?

Skimming this discussion, in general, I tend to agree with Eelco. A good
general approach would be to fully generify the framework and then vote to
back out the things which are really not helpful (for example, although
page
is technically a component, pages often have no models, so it might be a
good thing to a un-generify). Once we have found a practical/optimal level
of generification should we vote on it. Let's not throw the baby out with
the bathwater.

Also, for myself, I disagree that type safety is not a primary goal of
generics. Even if the API were completely clear already, I'd still prefer
more type safety.

Martijn Dashorst wrote:

On Wed, May 21, 2008 at 5:05 PM, Johan Compagner [EMAIL PROTECTED]

wrote:

Generics is type safety

I didn't say generics isn't type safety. But APPLYING generics for the

Wicket framework API *ISN'T* its primary goal. API clarity *IS*. Less

questions on the mailing list regarding DDC, ListView, etc. is the

main goal for applying generics in Wicket.

I am against this abuse big time -1000 from me

I'm -1000^1 for abusing my eyes and brain in

the way it currently is implemented in Wicket. It is completely and

utterly unusable for beginners. There is no way this is going to make

the number of questions on the mailinglist less (other than by scaring

away anyone that wants to actually use the framework)

Martijn

To unsubscribe, e-mail: [EMAIL PROTECTED]

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

--
View this message in context:
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17375350.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]

*Daniel Walmsley
Director, Firesyde http://firesyde.com/
e: [EMAIL PROTECTED]
m: +61404864141
*

Re: (Class? extends Page?) casting troubles

2008-05-24 Thread Matej Knopp

+1 on that too, except that I'd prefer the name GenericLink.

one problem though, suppose we have GenericWebMarkupContainer,
GenericPanel, GenericForm (maybe) etc, things like
findParent(Form.class) will no longer work, as it will have to be
findParent(GenericForm.class).

-Matej

On Sat, May 24, 2008 at 11:16 AM, John Patterson [EMAIL PROTECTED] wrote:



 Jonathan Locke wrote:

 Personally, I don't see this use of Void as something even remotely close
 to a reason to scrap it. I would happily use that construct every day. But
 that's just me.


 I completely agree with this and have found that specifying Void actually
 makes me a lot more conscious about the roll of the model.  I find it
 invaluable to have Eclipse quickfix assign to local variable automatically
 with the correct type from getModelObject().  Would be a terrible shame to
 lose this.

 Scrapping it on a case by case basis seems to make the most sense.  Is Link
 one of these cases?  It is *normally* used without a model.  For such common
 cases it is easy to create a non-generic subclass.  What is the problem with
 that?

 Is it possible to use a generic base class for users that want to have a
 type safe model like:

 class Link extends LinkGenericVoid
 {
 }

 LinkGenericT
 {
 }

 The generic base class could be used in core components.

 John
 --
 View this message in context: 
 http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17446015.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: (Class? extends Page?) casting troubles

2008-05-24 Thread Matej Knopp

Or maybe I took it too far and GenericLink and GenericButton would suffice :)

-Matej

On Sat, May 24, 2008 at 11:33 AM, Matej Knopp [EMAIL PROTECTED] wrote:
 +1 on that too, except that I'd prefer the name GenericLink.

 one problem though, suppose we have GenericWebMarkupContainer,
 GenericPanel, GenericForm (maybe) etc, things like
 findParent(Form.class) will no longer work, as it will have to be
 findParent(GenericForm.class).

 -Matej

 On Sat, May 24, 2008 at 11:16 AM, John Patterson [EMAIL PROTECTED] wrote:



 Jonathan Locke wrote:

 Personally, I don't see this use of Void as something even remotely close
 to a reason to scrap it. I would happily use that construct every day. But
 that's just me.


 I completely agree with this and have found that specifying Void actually
 makes me a lot more conscious about the roll of the model.  I find it
 invaluable to have Eclipse quickfix assign to local variable automatically
 with the correct type from getModelObject().  Would be a terrible shame to
 lose this.

 Scrapping it on a case by case basis seems to make the most sense.  Is Link
 one of these cases?  It is *normally* used without a model.  For such common
 cases it is easy to create a non-generic subclass.  What is the problem with
 that?

 Is it possible to use a generic base class for users that want to have a
 type safe model like:

 class Link extends LinkGenericVoid
 {
 }

 LinkGenericT
 {
 }

 The generic base class could be used in core components.

 John
 --
 View this message in context: 
 http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17446015.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: (Class? extends Page?) casting troubles

2008-05-24 Thread John Patterson




Matej Knopp-2 wrote:
 
 Or maybe I took it too far and GenericLink and GenericButton would suffice
 :)
 

Yeah, having components generic by default but making non-generic subclasses
for components that are *normally* used that way avoids the an explosion of
subclasses.

For example, I have created:

public class Container extends WebMarkupContainer
{
public Container(String id)
{
super(id);
setOutputMarkupPlaceholderTag(true);
}
}

but obviously the generic base class WebMarkupContainerT should be used as
the extension point in the hierarchy so there is no explosion.

The reason I put LinkGeneric rather than GenericLink was simply so that the
two options would appear next to each other in code completions.  But of
course in English GenericLink is more correct.  If we all spoke Spanish I
guess class names would work better with code completions ;)

John



-- 
View this message in context: 
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17446565.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: (Class? extends Page?) casting troubles

2008-05-24 Thread Gwyn Evans

On Sat, May 24, 2008 at 11:42 AM, John Patterson [EMAIL PROTECTED] wrote:

 The reason I put LinkGeneric rather than GenericLink was simply so that the
 two options would appear next to each other in code completions.  But of
 course in English GenericLink is more correct.

Good point regarding completions.  Anyway, flexible, english is!  Hmm.

/Gwyn
- http://www.yodaspeak.co.uk

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

Re: (Class? extends Page?) casting troubles

2008-05-24 Thread atul singh

As a java user I never missed generics.
Following opinion is just what i feel...
a) ClassCastExceptions never wasted my time more than a few minutes.
b)Also the advantage of code that spoke for itself could only be achieved
through a good developer (generics is not the cure to this, and many can
achieve this to some extent without generics).
c)One should look at this aspect for new features in wicket-- generics
included:: time spent on solving a problem by the end user VS avoiding it by
providing an out-of-box solution. IMO generics support IS NOT REQUIRED based
on above factor, and the time spent can be invested on some better
solutions/problems/use-cases.

On Sat, May 24, 2008 at 6:47 PM, Gwyn Evans [EMAIL PROTECTED] wrote:

 On Sat, May 24, 2008 at 11:42 AM, John Patterson [EMAIL PROTECTED]
 wrote:

  The reason I put LinkGeneric rather than GenericLink was simply so that
 the
  two options would appear next to each other in code completions.  But of
  course in English GenericLink is more correct.

 Good point regarding completions.  Anyway, flexible, english is!  Hmm.

 /Gwyn
 - http://www.yodaspeak.co.uk

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

Re: (Class? extends Page?) casting troubles

2008-05-24 Thread Igor Vaynberg

thats funny, my primary usecase is to use link WITH a model. so why
dont we keep Link generified and have a subclass VoidLink.

i am also not a big fan of using class hierarchy essentially as a
typedef, seems like a nasty hack to me (which i am willing to live
with). perhaps we can have wicket-void module that can contain all
these Void subclasses.

-igor

On Sat, May 24, 2008 at 2:24 AM, Johan Compagner [EMAIL PROTECTED] wrote:
+1

On Sat, May 24, 2008 at 8:09 AM, Daniel Walmsley [EMAIL PROTECTED] wrote:

I'm jumping into this conversation very late and I simply can't catch up
on
this entire thread, but isn't it possible to have a non-generic build of
the
generic framework for people that don't want to use generics?

Also, for myself, I disagree that type safety is not a primary goal of
generics. Even if the API were completely clear already, I'd still prefer
more type safety.

Martijn Dashorst wrote:

On Wed, May 21, 2008 at 5:05 PM, Johan Compagner [EMAIL PROTECTED]

wrote:

Generics is type safety

I didn't say generics isn't type safety. But APPLYING generics for the

Wicket framework API *ISN'T* its primary goal. API clarity *IS*. Less

questions on the mailing list regarding DDC, ListView, etc. is the

main goal for applying generics in Wicket.

I am against this abuse big time -1000 from me

I'm -1000^1 for abusing my eyes and brain in

the way it currently is implemented in Wicket. It is completely and

utterly unusable for beginners. There is no way this is going to make

the number of questions on the mailinglist less (other than by scaring

away anyone that wants to actually use the framework)

Martijn

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]

Daniel Walmsley
Director, Firesyde
e: [EMAIL PROTECTED]
m: +61404864141

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

Re: (Class? extends Page?) casting troubles

2008-05-24 Thread Matej Knopp

I don't buy the autocompletion as argument. Not with eclipse. It might
be difference when you do it first time and don't know the classes,
but every other time you just write GLink and eclipse autocompletes it
just fine.

-Matej

On Sat, May 24, 2008 at 3:17 PM, Gwyn Evans [EMAIL PROTECTED] wrote:
 On Sat, May 24, 2008 at 11:42 AM, John Patterson [EMAIL PROTECTED] wrote:

 The reason I put LinkGeneric rather than GenericLink was simply so that the
 two options would appear next to each other in code completions.  But of
 course in English GenericLink is more correct.

 Good point regarding completions.  Anyway, flexible, english is!  Hmm.

 /Gwyn
 - http://www.yodaspeak.co.uk

 -
 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: (Class? extends Page?) casting troubles

2008-05-22 Thread Joni Freeman

Yeah, it could even be in its separate utility class:

interface IModelT {}

class Component {
private IModel? model;

public IModel? getModel() {
return model;
}
}

public class Unsafe {
public static T IModelT cast(IModel? model) {
return (IModelT) model;
}
}

class MyComp extends Component {
public MyComp() {
IModelInteger model = Unsafe.cast(getModel());
}
}

I'm merely pointing out that there exists a solution to do unsafe cast
without getting compiler warning. Just like normal casts are handled.

I don't think Johan's all or nothing proposition is very pragmatic one.
Without generic IModel we do not get any API discoverability and our
APIs continue to suck. For instance, how can API user know what kind of
model this needs: MyJuicyComponent(String id, IModel model). At one
point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
model) but this convention is far from optimal. To be sure, one needs to
browse the sources...

Joni

On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
 Well, maybe it really is a hack that's too ugly. We might have two methods,
 
 default getModel() that doesn't cast it and alternative convenience
 one that does.
 
 -Matej
 
 On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED] wrote:
class Component {
private IModel? model;
 
public T IModelT getModel() {
return (IModelT) model;
}
}
 
  I like this. Even with the possible class cast exception. Because
  without generics, it doesn't leave you no other option than to cast it
  to your model, which isn't much better either, as you get the same
  result except that it looks uglier.
 
  -Matej
 
  On Wed, May 21, 2008 at 10:07 PM, Johan Compagner [EMAIL PROTECTED] wrote:
  no i am really against that falls V IModelV getModel() method
  that really abuses everything that generics stands for. For such a basic
  thing.
  this is really bad programming
  If we drop it we also pretty much drop it from IModel or have warnings in
  the user code.
 
  But then drop it completely is better because then we have to do a cast and
  you really think about that
  Not having that fake assurance..
 
  johan
 
 
  On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
  [EMAIL PROTECTED] wrote:
 
  Before we do a vote I want to make sure what our alternatives are.
 
  I still like Joni's alternative. I don't think they are an
  abomination, because the /potential/ class cast exception you get is
  the same as with current 1.3. But the benefit of documenting the model
  parameters in DDC, LV, etc. is HUGE.
 
  I really appreciate the time and effort that went into implementing
  the generification. But I also see what kind of mess this brought and
  I really don't like the Component generification part.
 
  Martijn
 
  On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg [EMAIL PROTECTED]
  wrote:
   ok so we pretty much have some core people wanting to back out the
   generics support.
  
   shall we start a vote? johan, gerolf and i have spent a ridiculous
   amount of time trying to generify the codebase and remove all the
   shitty warnings. if there is even a slight chance of this getting
   backed out i do not want to spend any more time on this until the
   issue is resolved.
  
   also we should halt m2 until this is resolved.
  
   personally i do not mind backing out generics, they turned out to be
   quiet a disappointment for me as well, but my feelings about this are
   not strong.
  
   we can still use generics such as setresponsepage(class? extends
   page) to gain bits of typesafety here and there, but if we remove
   them from component we obviously have to remove them from imodel.
  
   so lets start a vote with a parallel discussion thread just for this.
  
   -igor
  
   On Wed, May 21, 2008 at 8:19 AM, Martijn Dashorst
   [EMAIL PROTECTED] wrote:
   On Wed, May 21, 2008 at 5:05 PM, Johan Compagner [EMAIL PROTECTED]
  wrote:
   Generics is type safety
  
   I didn't say generics isn't type safety. But APPLYING generics for the
   Wicket framework API *ISN'T* its primary goal. API clarity *IS*. Less
   questions on the mailing list regarding DDC, ListView, etc. is the
   main goal for applying generics in Wicket.
  
   I am against this abuse big time -1000 from me
  
   I'm -1000^1 for abusing my eyes and brain in
   the way it currently is implemented in Wicket. It is completely and
   utterly unusable for beginners. There is no way this is going to make
   the number of questions on the mailinglist less (other than by scaring
   away anyone that wants to actually use the framework)
  
   Martijn
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]

Re: (Class? extends Page?) casting troubles

It isnt all or nothing.. i never said that

I just say if you dont want Component but you do want IModel
then you will get a warning at getModel()
we as a framework shouldnt hide the warning at that call.

But i am also curious how many people get really the model back from a
component (not counting specific places like repeaters.onpopuplate)

because i think most people do component.getModelObject() which then needs a
cast

But i like that extra helper method way more then having an extra
getUnsafeModel() method..
because thats explicit a developer has to really choose for it.

i think there are 3 options

1 keep it what we have now, tweak it with the feedback we get from 1.4M2
2 drop it on Component only and have a class like you described above to do
this:  IModelString model = Unsafe.cast(component.getModel()); (its still
a hack and a sense of false security but ok. if people really want this..)
3 drop it on Component and Model


i am +1 on 1
and -0 on 2 and 3

I still think it is not bad. and you can come around it really easy by just
creating a few extra classes like

StringLabel
NumberLabel
StringTextField
NumberTextField

if you only have a few of those extra all your code is cleanup

johan

On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED] wrote:

 Yeah, it could even be in its separate utility class:

 interface IModelT {}

 class Component {
private IModel? model;

 public IModel? getModel() {
return model;
}
 }

 public class Unsafe {
public static T IModelT cast(IModel? model) {
 return (IModelT) model;
}
 }

 class MyComp extends Component {
public MyComp() {
 IModelInteger model = Unsafe.cast(getModel());
}
 }

 I'm merely pointing out that there exists a solution to do unsafe cast
 without getting compiler warning. Just like normal casts are handled.

 I don't think Johan's all or nothing proposition is very pragmatic one.
 Without generic IModel we do not get any API discoverability and our
 APIs continue to suck. For instance, how can API user know what kind of
 model this needs: MyJuicyComponent(String id, IModel model). At one
 point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
 model) but this convention is far from optimal. To be sure, one needs to
 browse the sources...

 Joni

 On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
  Well, maybe it really is a hack that's too ugly. We might have two
 methods,
 
  default getModel() that doesn't cast it and alternative convenience
  one that does.
 
  -Matej
 
  On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 class Component {
 private IModel? model;
  
 public T IModelT getModel() {
 return (IModelT) model;
 }
 }
  
   I like this. Even with the possible class cast exception. Because
   without generics, it doesn't leave you no other option than to cast it
   to your model, which isn't much better either, as you get the same
   result except that it looks uglier.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
 [EMAIL PROTECTED] wrote:
   no i am really against that falls V IModelV getModel() method
   that really abuses everything that generics stands for. For such a
 basic
   thing.
   this is really bad programming
   If we drop it we also pretty much drop it from IModel or have warnings
 in
   the user code.
  
   But then drop it completely is better because then we have to do a
 cast and
   you really think about that
   Not having that fake assurance..
  
   johan
  
  
   On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
   [EMAIL PROTECTED] wrote:
  
   Before we do a vote I want to make sure what our alternatives are.
  
   I still like Joni's alternative. I don't think they are an
   abomination, because the /potential/ class cast exception you get is
   the same as with current 1.3. But the benefit of documenting the
 model
   parameters in DDC, LV, etc. is HUGE.
  
   I really appreciate the time and effort that went into implementing
   the generification. But I also see what kind of mess this brought and
   I really don't like the Component generification part.
  
   Martijn
  
   On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg 
 [EMAIL PROTECTED]
   wrote:
ok so we pretty much have some core people wanting to back out the
generics support.
   
shall we start a vote? johan, gerolf and i have spent a ridiculous
amount of time trying to generify the codebase and remove all the
shitty warnings. if there is even a slight chance of this getting
backed out i do not want to spend any more time on this until the
issue is resolved.
   
also we should halt m2 until this is resolved.
   
personally i do not mind backing out generics, they turned out to
 be
quiet a disappointment for me as well, but my feelings about this
 are
not strong.
   
we can still use generics such as setresponsepage(class? extends

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Matej Knopp

I would all be easier if getModel() and getModelObject() weren't
final. (I know there's a reason why they are, I'm not questioning it).

Then in your component subclass you coud do IModelInteger getModel()
{ return (IModelInteger)super.getModel() }, similiar with
getmodelobject so you wouldn't have casts all over places and it would
 be safer too).

-Matej

On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 It isnt all or nothing.. i never said that

 I just say if you dont want Component but you do want IModel
 then you will get a warning at getModel()
 we as a framework shouldnt hide the warning at that call.

 But i am also curious how many people get really the model back from a
 component (not counting specific places like repeaters.onpopuplate)

 because i think most people do component.getModelObject() which then needs a
 cast

 But i like that extra helper method way more then having an extra
 getUnsafeModel() method..
 because thats explicit a developer has to really choose for it.

 i think there are 3 options

 1 keep it what we have now, tweak it with the feedback we get from 1.4M2
 2 drop it on Component only and have a class like you described above to do
 this:  IModelString model = Unsafe.cast(component.getModel()); (its still
 a hack and a sense of false security but ok. if people really want this..)
 3 drop it on Component and Model


 i am +1 on 1
 and -0 on 2 and 3

 I still think it is not bad. and you can come around it really easy by just
 creating a few extra classes like

 StringLabel
 NumberLabel
 StringTextField
 NumberTextField

 if you only have a few of those extra all your code is cleanup

 johan

 On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED] wrote:

 Yeah, it could even be in its separate utility class:

 interface IModelT {}

 class Component {
private IModel? model;

 public IModel? getModel() {
return model;
}
 }

 public class Unsafe {
public static T IModelT cast(IModel? model) {
 return (IModelT) model;
}
 }

 class MyComp extends Component {
public MyComp() {
 IModelInteger model = Unsafe.cast(getModel());
}
 }

 I'm merely pointing out that there exists a solution to do unsafe cast
 without getting compiler warning. Just like normal casts are handled.

 I don't think Johan's all or nothing proposition is very pragmatic one.
 Without generic IModel we do not get any API discoverability and our
 APIs continue to suck. For instance, how can API user know what kind of
 model this needs: MyJuicyComponent(String id, IModel model). At one
 point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
 model) but this convention is far from optimal. To be sure, one needs to
 browse the sources...

 Joni

 On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
  Well, maybe it really is a hack that's too ugly. We might have two
 methods,
 
  default getModel() that doesn't cast it and alternative convenience
  one that does.
 
  -Matej
 
  On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 class Component {
 private IModel? model;
  
 public T IModelT getModel() {
 return (IModelT) model;
 }
 }
  
   I like this. Even with the possible class cast exception. Because
   without generics, it doesn't leave you no other option than to cast it
   to your model, which isn't much better either, as you get the same
   result except that it looks uglier.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
 [EMAIL PROTECTED] wrote:
   no i am really against that falls V IModelV getModel() method
   that really abuses everything that generics stands for. For such a
 basic
   thing.
   this is really bad programming
   If we drop it we also pretty much drop it from IModel or have warnings
 in
   the user code.
  
   But then drop it completely is better because then we have to do a
 cast and
   you really think about that
   Not having that fake assurance..
  
   johan
  
  
   On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
   [EMAIL PROTECTED] wrote:
  
   Before we do a vote I want to make sure what our alternatives are.
  
   I still like Joni's alternative. I don't think they are an
   abomination, because the /potential/ class cast exception you get is
   the same as with current 1.3. But the benefit of documenting the
 model
   parameters in DDC, LV, etc. is HUGE.
  
   I really appreciate the time and effort that went into implementing
   the generification. But I also see what kind of mess this brought and
   I really don't like the Component generification part.
  
   Martijn
  
   On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg 
 [EMAIL PROTECTED]
   wrote:
ok so we pretty much have some core people wanting to back out the
generics support.
   
shall we start a vote? johan, gerolf and i have spent a ridiculous
amount of time trying to generify the codebase and remove all the

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Matej Knopp

Although I'm not sure how many people call getModel/getModelObject
anyway. I think it's mostly about ListItems etc an i doubt anyone
would subclass it just because of getModel/getModelObject...

-Matej

On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED] wrote:
 I would all be easier if getModel() and getModelObject() weren't
 final. (I know there's a reason why they are, I'm not questioning it).

 Then in your component subclass you coud do IModelInteger getModel()
 { return (IModelInteger)super.getModel() }, similiar with
 getmodelobject so you wouldn't have casts all over places and it would
  be safer too).

 -Matej

 On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 It isnt all or nothing.. i never said that

 I just say if you dont want Component but you do want IModel
 then you will get a warning at getModel()
 we as a framework shouldnt hide the warning at that call.

 But i am also curious how many people get really the model back from a
 component (not counting specific places like repeaters.onpopuplate)

 because i think most people do component.getModelObject() which then needs a
 cast

 But i like that extra helper method way more then having an extra
 getUnsafeModel() method..
 because thats explicit a developer has to really choose for it.

 i think there are 3 options

 1 keep it what we have now, tweak it with the feedback we get from 1.4M2
 2 drop it on Component only and have a class like you described above to do
 this:  IModelString model = Unsafe.cast(component.getModel()); (its still
 a hack and a sense of false security but ok. if people really want this..)
 3 drop it on Component and Model


 i am +1 on 1
 and -0 on 2 and 3

 I still think it is not bad. and you can come around it really easy by just
 creating a few extra classes like

 StringLabel
 NumberLabel
 StringTextField
 NumberTextField

 if you only have a few of those extra all your code is cleanup

 johan

 On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED] wrote:

 Yeah, it could even be in its separate utility class:

 interface IModelT {}

 class Component {
private IModel? model;

 public IModel? getModel() {
return model;
}
 }

 public class Unsafe {
public static T IModelT cast(IModel? model) {
 return (IModelT) model;
}
 }

 class MyComp extends Component {
public MyComp() {
 IModelInteger model = Unsafe.cast(getModel());
}
 }

 I'm merely pointing out that there exists a solution to do unsafe cast
 without getting compiler warning. Just like normal casts are handled.

 I don't think Johan's all or nothing proposition is very pragmatic one.
 Without generic IModel we do not get any API discoverability and our
 APIs continue to suck. For instance, how can API user know what kind of
 model this needs: MyJuicyComponent(String id, IModel model). At one
 point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
 model) but this convention is far from optimal. To be sure, one needs to
 browse the sources...

 Joni

 On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
  Well, maybe it really is a hack that's too ugly. We might have two
 methods,
 
  default getModel() that doesn't cast it and alternative convenience
  one that does.
 
  -Matej
 
  On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 class Component {
 private IModel? model;
  
 public T IModelT getModel() {
 return (IModelT) model;
 }
 }
  
   I like this. Even with the possible class cast exception. Because
   without generics, it doesn't leave you no other option than to cast it
   to your model, which isn't much better either, as you get the same
   result except that it looks uglier.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
 [EMAIL PROTECTED] wrote:
   no i am really against that falls V IModelV getModel() method
   that really abuses everything that generics stands for. For such a
 basic
   thing.
   this is really bad programming
   If we drop it we also pretty much drop it from IModel or have warnings
 in
   the user code.
  
   But then drop it completely is better because then we have to do a
 cast and
   you really think about that
   Not having that fake assurance..
  
   johan
  
  
   On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
   [EMAIL PROTECTED] wrote:
  
   Before we do a vote I want to make sure what our alternatives are.
  
   I still like Joni's alternative. I don't think they are an
   abomination, because the /potential/ class cast exception you get is
   the same as with current 1.3. But the benefit of documenting the
 model
   parameters in DDC, LV, etc. is HUGE.
  
   I really appreciate the time and effort that went into implementing
   the generification. But I also see what kind of mess this brought and
   I really don't like the Component generification part.
  
   Martijn
  
   On Wed, May 21, 2008 at 9:24 PM, Igor

Re: (Class? extends Page?) casting troubles

But if you are willing to subclass it and make that extra method

Then why not subclass the component itself and for example:
IntegerTextFieldInteger
thats the same thing 1 subclass, no extra generics in your code...

johan


On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED] wrote:

 I would all be easier if getModel() and getModelObject() weren't
 final. (I know there's a reason why they are, I'm not questioning it).

 Then in your component subclass you coud do IModelInteger getModel()
 { return (IModelInteger)super.getModel() }, similiar with
 getmodelobject so you wouldn't have casts all over places and it would
  be safer too).

 -Matej

 On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  It isnt all or nothing.. i never said that
 
  I just say if you dont want Component but you do want IModel
  then you will get a warning at getModel()
  we as a framework shouldnt hide the warning at that call.
 
  But i am also curious how many people get really the model back from a
  component (not counting specific places like repeaters.onpopuplate)
 
  because i think most people do component.getModelObject() which then
 needs a
  cast
 
  But i like that extra helper method way more then having an extra
  getUnsafeModel() method..
  because thats explicit a developer has to really choose for it.
 
  i think there are 3 options
 
  1 keep it what we have now, tweak it with the feedback we get from 1.4M2
  2 drop it on Component only and have a class like you described above to
 do
  this:  IModelString model = Unsafe.cast(component.getModel()); (its
 still
  a hack and a sense of false security but ok. if people really want
 this..)
  3 drop it on Component and Model
 
 
  i am +1 on 1
  and -0 on 2 and 3
 
  I still think it is not bad. and you can come around it really easy by
 just
  creating a few extra classes like
 
  StringLabel
  NumberLabel
  StringTextField
  NumberTextField
 
  if you only have a few of those extra all your code is cleanup
 
  johan
 
  On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED]
 wrote:
 
  Yeah, it could even be in its separate utility class:
 
  interface IModelT {}
 
  class Component {
 private IModel? model;
 
  public IModel? getModel() {
 return model;
 }
  }
 
  public class Unsafe {
 public static T IModelT cast(IModel? model) {
  return (IModelT) model;
 }
  }
 
  class MyComp extends Component {
 public MyComp() {
  IModelInteger model = Unsafe.cast(getModel());
 }
  }
 
  I'm merely pointing out that there exists a solution to do unsafe cast
  without getting compiler warning. Just like normal casts are handled.
 
  I don't think Johan's all or nothing proposition is very pragmatic one.
  Without generic IModel we do not get any API discoverability and our
  APIs continue to suck. For instance, how can API user know what kind of
  model this needs: MyJuicyComponent(String id, IModel model). At one
  point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
  model) but this convention is far from optimal. To be sure, one needs to
  browse the sources...
 
  Joni
 
  On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
   Well, maybe it really is a hack that's too ugly. We might have two
  methods,
  
   default getModel() that doesn't cast it and alternative convenience
   one that does.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
  wrote:
  class Component {
  private IModel? model;
   
  public T IModelT getModel() {
  return (IModelT) model;
  }
  }
   
I like this. Even with the possible class cast exception. Because
without generics, it doesn't leave you no other option than to cast
 it
to your model, which isn't much better either, as you get the same
result except that it looks uglier.
   
-Matej
   
On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
  [EMAIL PROTECTED] wrote:
no i am really against that falls V IModelV getModel() method
that really abuses everything that generics stands for. For such a
  basic
thing.
this is really bad programming
If we drop it we also pretty much drop it from IModel or have
 warnings
  in
the user code.
   
But then drop it completely is better because then we have to do a
  cast and
you really think about that
Not having that fake assurance..
   
johan
   
   
On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:
   
Before we do a vote I want to make sure what our alternatives are.
   
I still like Joni's alternative. I don't think they are an
abomination, because the /potential/ class cast exception you get
 is
the same as with current 1.3. But the benefit of documenting the
  model
parameters in DDC, LV, etc. is HUGE.
   
I really appreciate the time and effort that went into
 implementing
the

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Martijn Dashorst

I often do the following:

populateItem(ListItem item) {
add(new Link(edit, item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
}

So both are used often, but mostly to pass things around.

Martijn

On Thu, May 22, 2008 at 11:25 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 getModel() i agree, but getModelObject() is something that is used the most
 if i have to guess.

 Because in an onSubmit() of a form or a onClick of a Link what do most of
 you do?

 onSubmit()
 {
 dao.save(getModelObject())
 }

 onClick()
 {
 dao.delete(getModelObject())
 }

 johan

 On Thu, May 22, 2008 at 10:05 AM, Matej Knopp [EMAIL PROTECTED] wrote:

 Although I'm not sure how many people call getModel/getModelObject
 anyway. I think it's mostly about ListItems etc an i doubt anyone
 would subclass it just because of getModel/getModelObject...

 -Matej

 On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED]
 wrote:
  I would all be easier if getModel() and getModelObject() weren't
  final. (I know there's a reason why they are, I'm not questioning it).
 
  Then in your component subclass you coud do IModelInteger getModel()
  { return (IModelInteger)super.getModel() }, similiar with
  getmodelobject so you wouldn't have casts all over places and it would
   be safer too).
 
  -Matej
 
  On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  It isnt all or nothing.. i never said that
 
  I just say if you dont want Component but you do want IModel
  then you will get a warning at getModel()
  we as a framework shouldnt hide the warning at that call.
 
  But i am also curious how many people get really the model back from a
  component (not counting specific places like repeaters.onpopuplate)
 
  because i think most people do component.getModelObject() which then
 needs a
  cast
 
  But i like that extra helper method way more then having an extra
  getUnsafeModel() method..
  because thats explicit a developer has to really choose for it.
 
  i think there are 3 options
 
  1 keep it what we have now, tweak it with the feedback we get from
 1.4M2
  2 drop it on Component only and have a class like you described above
 to do
  this:  IModelString model = Unsafe.cast(component.getModel()); (its
 still
  a hack and a sense of false security but ok. if people really want
 this..)
  3 drop it on Component and Model
 
 
  i am +1 on 1
  and -0 on 2 and 3
 
  I still think it is not bad. and you can come around it really easy by
 just
  creating a few extra classes like
 
  StringLabel
  NumberLabel
  StringTextField
  NumberTextField
 
  if you only have a few of those extra all your code is cleanup
 
  johan
 
  On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED]
 wrote:
 
  Yeah, it could even be in its separate utility class:
 
  interface IModelT {}
 
  class Component {
 private IModel? model;
 
  public IModel? getModel() {
 return model;
 }
  }
 
  public class Unsafe {
 public static T IModelT cast(IModel? model) {
  return (IModelT) model;
 }
  }
 
  class MyComp extends Component {
 public MyComp() {
  IModelInteger model = Unsafe.cast(getModel());
 }
  }
 
  I'm merely pointing out that there exists a solution to do unsafe cast
  without getting compiler warning. Just like normal casts are handled.
 
  I don't think Johan's all or nothing proposition is very pragmatic one.
  Without generic IModel we do not get any API discoverability and our
  APIs continue to suck. For instance, how can API user know what kind of
  model this needs: MyJuicyComponent(String id, IModel model). At one
  point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
  model) but this convention is far from optimal. To be sure, one needs
 to
  browse the sources...
 
  Joni
 
  On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
   Well, maybe it really is a hack that's too ugly. We might have two
  methods,
  
   default getModel() that doesn't cast it and alternative convenience
   one that does.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 
  wrote:
  class Component {
  private IModel? model;
   
  public T IModelT getModel() {
  return (IModelT) model;
  }
  }
   
I like this. Even with the possible class cast exception. Because
without generics, it doesn't leave you no other option than to cast
 it
to your model, which isn't much better either, as you get the same
result except that it looks uglier.
   
-Matej
   
On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
  [EMAIL PROTECTED] wrote:
no i am really against that falls V IModelV getModel() method
that really abuses everything that generics stands for. For such a
  basic
thing.
this is really bad programming
If we drop it we also pretty much drop it from IModel or have
 warnings

Re: (Class? extends Page?) casting troubles

getModel() i agree, but getModelObject() is something that is used the most
if i have to guess.

Because in an onSubmit() of a form or a onClick of a Link what do most of
you do?

onSubmit()
{
dao.save(getModelObject())
}

onClick()
{
dao.delete(getModelObject())
}

johan

On Thu, May 22, 2008 at 10:05 AM, Matej Knopp [EMAIL PROTECTED] wrote:

 Although I'm not sure how many people call getModel/getModelObject
 anyway. I think it's mostly about ListItems etc an i doubt anyone
 would subclass it just because of getModel/getModelObject...

 -Matej

 On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED]
 wrote:
  I would all be easier if getModel() and getModelObject() weren't
  final. (I know there's a reason why they are, I'm not questioning it).
 
  Then in your component subclass you coud do IModelInteger getModel()
  { return (IModelInteger)super.getModel() }, similiar with
  getmodelobject so you wouldn't have casts all over places and it would
   be safer too).
 
  -Matej
 
  On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  It isnt all or nothing.. i never said that
 
  I just say if you dont want Component but you do want IModel
  then you will get a warning at getModel()
  we as a framework shouldnt hide the warning at that call.
 
  But i am also curious how many people get really the model back from a
  component (not counting specific places like repeaters.onpopuplate)
 
  because i think most people do component.getModelObject() which then
 needs a
  cast
 
  But i like that extra helper method way more then having an extra
  getUnsafeModel() method..
  because thats explicit a developer has to really choose for it.
 
  i think there are 3 options
 
  1 keep it what we have now, tweak it with the feedback we get from
 1.4M2
  2 drop it on Component only and have a class like you described above
 to do
  this:  IModelString model = Unsafe.cast(component.getModel()); (its
 still
  a hack and a sense of false security but ok. if people really want
 this..)
  3 drop it on Component and Model
 
 
  i am +1 on 1
  and -0 on 2 and 3
 
  I still think it is not bad. and you can come around it really easy by
 just
  creating a few extra classes like
 
  StringLabel
  NumberLabel
  StringTextField
  NumberTextField
 
  if you only have a few of those extra all your code is cleanup
 
  johan
 
  On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED]
 wrote:
 
  Yeah, it could even be in its separate utility class:
 
  interface IModelT {}
 
  class Component {
 private IModel? model;
 
  public IModel? getModel() {
 return model;
 }
  }
 
  public class Unsafe {
 public static T IModelT cast(IModel? model) {
  return (IModelT) model;
 }
  }
 
  class MyComp extends Component {
 public MyComp() {
  IModelInteger model = Unsafe.cast(getModel());
 }
  }
 
  I'm merely pointing out that there exists a solution to do unsafe cast
  without getting compiler warning. Just like normal casts are handled.
 
  I don't think Johan's all or nothing proposition is very pragmatic one.
  Without generic IModel we do not get any API discoverability and our
  APIs continue to suck. For instance, how can API user know what kind of
  model this needs: MyJuicyComponent(String id, IModel model). At one
  point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
  model) but this convention is far from optimal. To be sure, one needs
 to
  browse the sources...
 
  Joni
 
  On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
   Well, maybe it really is a hack that's too ugly. We might have two
  methods,
  
   default getModel() that doesn't cast it and alternative convenience
   one that does.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 
  wrote:
  class Component {
  private IModel? model;
   
  public T IModelT getModel() {
  return (IModelT) model;
  }
  }
   
I like this. Even with the possible class cast exception. Because
without generics, it doesn't leave you no other option than to cast
 it
to your model, which isn't much better either, as you get the same
result except that it looks uglier.
   
-Matej
   
On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
  [EMAIL PROTECTED] wrote:
no i am really against that falls V IModelV getModel() method
that really abuses everything that generics stands for. For such a
  basic
thing.
this is really bad programming
If we drop it we also pretty much drop it from IModel or have
 warnings
  in
the user code.
   
But then drop it completely is better because then we have to do a
  cast and
you really think about that
Not having that fake assurance..
   
johan
   
   
On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:
   
Before we do a vote I want to make sure what our alternatives
 are.
   
I

Re: (Class? extends Page?) casting troubles



Hi Johan,


I thing that the example below is exactly the thing that generics are pretty
good:

populateItem(ListItemPerson item) {
   add(new LinkPerson(edit, item.getModel()) {
   public void onClick() {
   setResponsePage(new EditPage(getModelObject()));
   }
   });

(and EditPage is by itself already generified to Person)


well, just that the LinkPerson is IMHO redundant and unnecessary(just dropped 
a note to Martijn, but since you brought that up...)


populateItem(final ListItemPerson item) {
item.add(new Link(edit) {
public void onClick() {
setResponsePage(new EditPage(item.getModelObject()));
}
});

So, it might have sense with ListItem, but not necissarily with Link...

Regards, --- Jan.



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

Re: (Class? extends Page?) casting troubles

exactly Repeaters is very nice that the populateItem is generified.. I think
that is really handy..

And if the EditPage now wanted a specific type then you need now to cast at
that place..

I thing that the example below is exactly the thing that generics are pretty
good:

populateItem(ListItemPerson item) {
   add(new LinkPerson(edit, item.getModel()) {
   public void onClick() {
   setResponsePage(new EditPage(getModelObject()));
   }
   });

(and EditPage is by itself already generified to Person)

This is just a perfect thing that i say yes very nice you see exactly what
the code should do
and cant say that this is really verbose..

johan



On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 I often do the following:

 populateItem(ListItem item) {
add(new Link(edit, item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
 }

 So both are used often, but mostly to pass things around.

 Martijn

 On Thu, May 22, 2008 at 11:25 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  getModel() i agree, but getModelObject() is something that is used the
 most
  if i have to guess.
 
  Because in an onSubmit() of a form or a onClick of a Link what do most of
  you do?
 
  onSubmit()
  {
  dao.save(getModelObject())
  }
 
  onClick()
  {
  dao.delete(getModelObject())
  }
 
  johan
 
  On Thu, May 22, 2008 at 10:05 AM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 
  Although I'm not sure how many people call getModel/getModelObject
  anyway. I think it's mostly about ListItems etc an i doubt anyone
  would subclass it just because of getModel/getModelObject...
 
  -Matej
 
  On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED]
  wrote:
   I would all be easier if getModel() and getModelObject() weren't
   final. (I know there's a reason why they are, I'm not questioning it).
  
   Then in your component subclass you coud do IModelInteger getModel()
   { return (IModelInteger)super.getModel() }, similiar with
   getmodelobject so you wouldn't have casts all over places and it would
be safer too).
  
   -Matej
  
   On Thu, May 22, 2008 at 9:39 AM, Johan Compagner 
 [EMAIL PROTECTED]
  wrote:
   It isnt all or nothing.. i never said that
  
   I just say if you dont want Component but you do want IModel
   then you will get a warning at getModel()
   we as a framework shouldnt hide the warning at that call.
  
   But i am also curious how many people get really the model back from
 a
   component (not counting specific places like repeaters.onpopuplate)
  
   because i think most people do component.getModelObject() which then
  needs a
   cast
  
   But i like that extra helper method way more then having an extra
   getUnsafeModel() method..
   because thats explicit a developer has to really choose for it.
  
   i think there are 3 options
  
   1 keep it what we have now, tweak it with the feedback we get from
  1.4M2
   2 drop it on Component only and have a class like you described
 above
  to do
   this:  IModelString model = Unsafe.cast(component.getModel()); (its
  still
   a hack and a sense of false security but ok. if people really want
  this..)
   3 drop it on Component and Model
  
  
   i am +1 on 1
   and -0 on 2 and 3
  
   I still think it is not bad. and you can come around it really easy
 by
  just
   creating a few extra classes like
  
   StringLabel
   NumberLabel
   StringTextField
   NumberTextField
  
   if you only have a few of those extra all your code is cleanup
  
   johan
  
   On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED]
  wrote:
  
   Yeah, it could even be in its separate utility class:
  
   interface IModelT {}
  
   class Component {
  private IModel? model;
  
   public IModel? getModel() {
  return model;
  }
   }
  
   public class Unsafe {
  public static T IModelT cast(IModel? model) {
   return (IModelT) model;
  }
   }
  
   class MyComp extends Component {
  public MyComp() {
   IModelInteger model = Unsafe.cast(getModel());
  }
   }
  
   I'm merely pointing out that there exists a solution to do unsafe
 cast
   without getting compiler warning. Just like normal casts are
 handled.
  
   I don't think Johan's all or nothing proposition is very pragmatic
 one.
   Without generic IModel we do not get any API discoverability and our
   APIs continue to suck. For instance, how can API user know what kind
 of
   model this needs: MyJuicyComponent(String id, IModel model). At one
   point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
   model) but this convention is far from optimal. To be sure, one
 needs
  to
   browse the sources...
  
   Joni
  
   On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
Well, maybe it really is a hack that's too ugly. We might have two
   methods,
   
default getModel() that doesn't cast it and alternative
 convenience

Re: (Class? extends Page?) casting troubles

Yeah that is the problem with Generics

You cant say take the T from the model you get in the constructor
Then everything would be perfect.

But i really dont think that Person in link is redundant why is it?
You call later on getModelObject() on it.. so you use the model/modelobject
of Link
so you need to say what Link has..

johan


On Thu, May 22, 2008 at 11:45 AM, Jan Kriesten [EMAIL PROTECTED]
wrote:


 Hi Johan,

  I thing that the example below is exactly the thing that generics are
 pretty
 good:

 populateItem(ListItemPerson item) {
   add(new LinkPerson(edit, item.getModel()) {
   public void onClick() {
   setResponsePage(new EditPage(getModelObject()));
   }
   });

 (and EditPage is by itself already generified to Person)


 well, just that the LinkPerson is IMHO redundant and unnecessary(just
 dropped a note to Martijn, but since you brought that up...)

 populateItem(final ListItemPerson item) {
item.add(new Link(edit) {
public void onClick() {
setResponsePage(new EditPage(item.getModelObject()));
}
});

 So, it might have sense with ListItem, but not necissarily with Link...

 Regards, --- Jan.




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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Peter Ertl

+1 for finishing generics (no matter how ugly it gets), then  
refactoring / removing the things that suck


Am 22.05.2008 um 11:37 schrieb Johan Compagner:

exactly Repeaters is very nice that the populateItem is generified..  
I think

that is really handy..

And if the EditPage now wanted a specific type then you need now to  
cast at

that place..

I thing that the example below is exactly the thing that generics  
are pretty

good:

populateItem(ListItemPerson item) {
  add(new LinkPerson(edit, item.getModel()) {
  public void onClick() {
  setResponsePage(new EditPage(getModelObject()));
  }
  });

(and EditPage is by itself already generified to Person)

This is just a perfect thing that i say yes very nice you see  
exactly what

the code should do
and cant say that this is really verbose..

johan



On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:


I often do the following:

populateItem(ListItem item) {
  add(new Link(edit, item.getModel()) {
  public void onClick() {
  setResponsePage(new EditPage(getModelObject()));
  }
  });
}

So both are used often, but mostly to pass things around.

Martijn

On Thu, May 22, 2008 at 11:25 AM, Johan Compagner [EMAIL PROTECTED] 


wrote:
getModel() i agree, but getModelObject() is something that is used  
the

most

if i have to guess.

Because in an onSubmit() of a form or a onClick of a Link what do  
most of

you do?

onSubmit()
{
dao.save(getModelObject())
}

onClick()
{
dao.delete(getModelObject())
}

johan

On Thu, May 22, 2008 at 10:05 AM, Matej Knopp  
[EMAIL PROTECTED]

wrote:



Although I'm not sure how many people call getModel/getModelObject
anyway. I think it's mostly about ListItems etc an i doubt anyone
would subclass it just because of getModel/getModelObject...

-Matej

On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED] 


wrote:

I would all be easier if getModel() and getModelObject() weren't
final. (I know there's a reason why they are, I'm not  
questioning it).


Then in your component subclass you coud do IModelInteger  
getModel()

{ return (IModelInteger)super.getModel() }, similiar with
getmodelobject so you wouldn't have casts all over places and it  
would

be safer too).

-Matej

On Thu, May 22, 2008 at 9:39 AM, Johan Compagner 

[EMAIL PROTECTED]

wrote:

It isnt all or nothing.. i never said that

I just say if you dont want Component but you do want IModel
then you will get a warning at getModel()
we as a framework shouldnt hide the warning at that call.

But i am also curious how many people get really the model back  
from

a
component (not counting specific places like  
repeaters.onpopuplate)


because i think most people do component.getModelObject() which  
then

needs a

cast

But i like that extra helper method way more then having an extra
getUnsafeModel() method..
because thats explicit a developer has to really choose for it.

i think there are 3 options

1 keep it what we have now, tweak it with the feedback we get  
from

1.4M2

2 drop it on Component only and have a class like you described

above

to do
this:  IModelString model =  
Unsafe.cast(component.getModel()); (its

still
a hack and a sense of false security but ok. if people really  
want

this..)

3 drop it on Component and Model


i am +1 on 1
and -0 on 2 and 3

I still think it is not bad. and you can come around it really  
easy

by

just

creating a few extra classes like

StringLabel
NumberLabel
StringTextField
NumberTextField

if you only have a few of those extra all your code is cleanup

johan

On Thu, May 22, 2008 at 9:12 AM, Joni Freeman  
[EMAIL PROTECTED]

wrote:



Yeah, it could even be in its separate utility class:

interface IModelT {}

class Component {
  private IModel? model;

   public IModel? getModel() {
  return model;
  }
}

public class Unsafe {
  public static T IModelT cast(IModel? model) {
   return (IModelT) model;
  }
}

class MyComp extends Component {
  public MyComp() {
   IModelInteger model = Unsafe.cast(getModel());
  }
}

I'm merely pointing out that there exists a solution to do  
unsafe

cast

without getting compiler warning. Just like normal casts are

handled.


I don't think Johan's all or nothing proposition is very  
pragmatic

one.
Without generic IModel we do not get any API discoverability  
and our
APIs continue to suck. For instance, how can API user know  
what kind

of
model this needs: MyJuicyComponent(String id, IModel model).  
At one
point we did this: MyJuicyComponent(String id, IModel/ 
*Chocolate*/

model) but this convention is far from optimal. To be sure, one

needs

to

browse the sources...

Joni

On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
Well, maybe it really is a hack that's too ugly. We might  
have two

methods,


default getModel() that doesn't cast it and alternative

convenience

one that does.

-Matej

On Wed, May 21, 2008 at 10:10 PM, Matej Knopp 

[EMAIL PROTECTED]



wrote:

 class

Re: (Class? extends Page?) casting troubles



Hi Johan,


But i really dont think that Person in link is redundant why is it?


the point was, that in this case Link simply doesn't need to have given a model 
at all, since you can access the surrounding final vars (you can access the item 
in onClick):



populateItem(final ListItemPerson item) {
   item.add(new Link(edit) {
   public void onClick() {
   setResponsePage(new EditPage(item.getModelObject()));
   }
   });


What else could you do/access in Link what is not possible with this approach?


Regards, --- Jan.


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

Re: (Class? extends Page?) casting troubles



Hi Johan,


ahh yes thats true i overlooked your changes..
then yes currently you have to do new LinkVoid (to get rid of the
warnings)


there are quite annoying many cases of this kind, where you really just don't 
need to add models to components and have to boilerplate these with Void or 
anything else.


So, I can really understand and support Martijns objections to have Component 
generified just for the sake of it.


If it's to clearify the API - make those cases generic or have them implement a 
different IModel (like ListModel e.g.).


Best regards, --- Jan.



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

Re: (Class? extends Page?) casting troubles

ahh yes thats true i overlooked your changes..

then yes currently you have to do new LinkVoid (to get rid of the
warnings)

johan


On Thu, May 22, 2008 at 11:54 AM, Jan Kriesten [EMAIL PROTECTED]
wrote:


 Hi Johan,

  But i really dont think that Person in link is redundant why is it?


 the point was, that in this case Link simply doesn't need to have given a
 model at all, since you can access the surrounding final vars (you can
 access the item in onClick):

  populateItem(final ListItemPerson item) {
   item.add(new Link(edit) {
   public void onClick() {
   setResponsePage(new EditPage(item.getModelObject()));
   }
   });


 What else could you do/access in Link what is not possible with this
 approach?



 Regards, --- Jan.


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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Sebastiaan van Erk


Jan Kriesten wrote:


Hi Johan,


ahh yes thats true i overlooked your changes..
then yes currently you have to do new LinkVoid (to get rid of the
warnings)


there are quite annoying many cases of this kind, where you really just 
don't need to add models to components and have to boilerplate these 
with Void or anything else.


So, I can really understand and support Martijns objections to have 
Component generified just for the sake of it.


Well, I'd hardly say it's just for the sake of it! It's *required* to 
*properly* generify Wicket. Due to the strong coupling in the design of 
Wicket of a component to a model, when you refer to a component you 
*must* specify the type of the model... Anything else is just plain bad 
(and strange) use of generics... :-(


If it's to clearify the API - make those cases generic or have them 
implement a different IModel (like ListModel e.g.).


I'm very much against using generics to do something other from what 
generics where meant to do (i.e., type safety).


Regards,
Sebastiaan


Best regards, --- Jan.



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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles

But if you have a lot of LinkVoid for you cases
then make 1 simple subclass of Link

johan


On Thu, May 22, 2008 at 12:41 PM, Jan Kriesten [EMAIL PROTECTED]
wrote:


 Hi Johan,

  ahh yes thats true i overlooked your changes..
 then yes currently you have to do new LinkVoid (to get rid of the
 warnings)


 there are quite annoying many cases of this kind, where you really just
 don't need to add models to components and have to boilerplate these with
 Void or anything else.

 So, I can really understand and support Martijns objections to have
 Component generified just for the sake of it.

 If it's to clearify the API - make those cases generic or have them
 implement a different IModel (like ListModel e.g.).

 Best regards, --- Jan.




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

Re: (Class? extends Page?) casting troubles



hi sebastiaan,

I'm very much against using generics to do something other from what 
generics where meant to do (i.e., type safety).


i'm all in when you're talking about type safety. having compile-time checks on 
the types is a time-saver during development.


with wicket generics it's just that the time-saver get's in it's own way, i.e. 
bringing in so much boilerplate, that coding is getting harder to do right 
(besides from source readability).


regards, --- jan.

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

Re: (Class? extends Page?) casting troubles



hi johan,


But if you have a lot of LinkVoid for you cases
then make 1 simple subclass of Link


so anyone make your own wrapper to get readable sources again? let me think: how 
many webmarkupcontainer, link, page etc. classes do i use with void?


i don't think that's a serious option.

--- jan.



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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Sebastiaan van Erk


Jan Kriesten wrote:


hi johan,


But if you have a lot of LinkVoid for you cases
then make 1 simple subclass of Link


so anyone make your own wrapper to get readable sources again? let me 
think: how many webmarkupcontainer, link, page etc. classes do i use 
with void?


i don't think that's a serious option.


While LinkVoid is somewhat more verbose than Link, I seriously think 
that people are making too big a deal out of it. Is LinkVoid really 
that unreadable? Is it really that hard to code? Personally I think 
*adds* to the clarity; it says you're not going to use the model of the 
Link component.


Regards,
Sebastiaan


--- jan.



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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles

harder to comprehend??
come on, you must be kidding!

Link is many times uses (you did give an example your self 2 emails back) as
a model object holder
So if developers use it sometimes as just a link and sometimes just as an
object.

I think if we made Link default Object that many people would complain..

johan


On Thu, May 22, 2008 at 1:49 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 It is. If you haven't noticed, about a bazillion folks around the
 world are discarding Java because of its verbosity. Having to type
 LinkVoid(link) {} really makes it harder to comprehend. Why does
 the link need a type? It is not needed. what is not needed doesn't
 need to be specified. Period.

 Martijn

 On Thu, May 22, 2008 at 1:45 PM, Sebastiaan van Erk [EMAIL PROTECTED]
 wrote:
  Jan Kriesten wrote:
 
  hi johan,
 
  But if you have a lot of LinkVoid for you cases
  then make 1 simple subclass of Link
 
  so anyone make your own wrapper to get readable sources again? let me
  think: how many webmarkupcontainer, link, page etc. classes do i use
 with
  void?
 
  i don't think that's a serious option.
 
  While LinkVoid is somewhat more verbose than Link, I seriously think
 that
  people are making too big a deal out of it. Is LinkVoid really that
  unreadable? Is it really that hard to code? Personally I think *adds* to
 the
  clarity; it says you're not going to use the model of the Link component.
 
  Regards,
  Sebastiaan
 
  --- jan.
 
 
 
  -
  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: (Class? extends Page?) casting troubles

harder to comprehend??
come on, you must be kidding!

Link is many times uses (you did give an example your self 2 emails back) as
a model object holder
So if developers use it sometimes as just a link and sometimes just as an
object.

I think if we made Link default Object that many people would complain..

johan


On Thu, May 22, 2008 at 1:49 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 It is. If you haven't noticed, about a bazillion folks around the
 world are discarding Java because of its verbosity. Having to type
 LinkVoid(link) {} really makes it harder to comprehend. Why does
 the link need a type? It is not needed. what is not needed doesn't
 need to be specified. Period.

 Martijn

 On Thu, May 22, 2008 at 1:45 PM, Sebastiaan van Erk [EMAIL PROTECTED]
 wrote:
  Jan Kriesten wrote:
 
  hi johan,
 
  But if you have a lot of LinkVoid for you cases
  then make 1 simple subclass of Link
 
  so anyone make your own wrapper to get readable sources again? let me
  think: how many webmarkupcontainer, link, page etc. classes do i use
 with
  void?
 
  i don't think that's a serious option.
 
  While LinkVoid is somewhat more verbose than Link, I seriously think
 that
  people are making too big a deal out of it. Is LinkVoid really that
  unreadable? Is it really that hard to code? Personally I think *adds* to
 the
  clarity; it says you're not going to use the model of the Link component.
 
  Regards,
  Sebastiaan
 
  --- jan.
 
 
 
  -
  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: (Class? extends Page?) casting troubles

2008-05-22 Thread Jeremy Thomerson

I haven't said anything up to this point, but we really don't seem to be
getting anywhere with what is turning into a religious war.  I, for one,
have already started using 1.4, and love the generics, despite the extra
verbosity.  It gives me extra type safety and code self-documentation.  I
would be very against having the framework do a cast as has been suggested
on here, because that is a hack, and not useful for anything - I lose the
value of generics because the compiler is no longer checking my type safety
throughout the application.  If I came to a framework without previous
experience with it, and discovered that ugly hack, I would be worried about
the quality of all of the code.

I think that we should:
 - continue with 1.4-M2
 - create a wiki page where we can get one master list of  things we like
and don't like
 - see what we can do to address those

We're really not getting anywhere with this conversation until we have a
finite list, and some options for each con on the list.  Then we can either
choose the best options or say forget it.

-- 
Jeremy Thomerson
http://www.wickettraining.com

On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten [EMAIL PROTECTED]
wrote:


 hi sebastiaan,

  I'm very much against using generics to do something other from what
 generics where meant to do (i.e., type safety).


 i'm all in when you're talking about type safety. having compile-time
 checks on the types is a time-saver during development.

 with wicket generics it's just that the time-saver get's in it's own way,
 i.e. bringing in so much boilerplate, that coding is getting harder to do
 right (besides from source readability).


 regards, --- jan.

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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Jeremy Thomerson

I forgot to mention... when I said code self-documentation, I meant that
there are places where I have a component or page that takes two models.
Which is which?  I document it by the parameter name (i.e.
MyComponent(IModel fooModel, IModel barModel), but it is much better (and
the compiler checks it for me) having MyComponent(IModelFoo fooModel,
IModelBar barModel).

-- 
Jeremy Thomerson
http://www.wickettraining.com

On Thu, May 22, 2008 at 8:32 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:

 I haven't said anything up to this point, but we really don't seem to be
 getting anywhere with what is turning into a religious war.  I, for one,
 have already started using 1.4, and love the generics, despite the extra
 verbosity.  It gives me extra type safety and code self-documentation.  I
 would be very against having the framework do a cast as has been suggested
 on here, because that is a hack, and not useful for anything - I lose the
 value of generics because the compiler is no longer checking my type safety
 throughout the application.  If I came to a framework without previous
 experience with it, and discovered that ugly hack, I would be worried about
 the quality of all of the code.

 I think that we should:
  - continue with 1.4-M2
  - create a wiki page where we can get one master list of  things we like
 and don't like
  - see what we can do to address those

 We're really not getting anywhere with this conversation until we have a
 finite list, and some options for each con on the list.  Then we can either
 choose the best options or say forget it.

 --
 Jeremy Thomerson
 http://www.wickettraining.com

 On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten [EMAIL PROTECTED]
 wrote:


 hi sebastiaan,

  I'm very much against using generics to do something other from what
 generics where meant to do (i.e., type safety).


 i'm all in when you're talking about type safety. having compile-time
 checks on the types is a time-saver during development.

 with wicket generics it's just that the time-saver get's in it's own way,
 i.e. bringing in so much boilerplate, that coding is getting harder to do
 right (besides from source readability).


 regards, --- jan.

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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Sebastiaan van Erk


Jeremy Thomerson wrote:

I haven't said anything up to this point, but we really don't seem to be
getting anywhere with what is turning into a religious war.  I, for one,
have already started using 1.4, and love the generics, despite the extra
verbosity.  It gives me extra type safety and code self-documentation.  I
would be very against having the framework do a cast as has been suggested
on here, because that is a hack, and not useful for anything - I lose the
value of generics because the compiler is no longer checking my type safety
throughout the application.  If I came to a framework without previous
experience with it, and discovered that ugly hack, I would be worried about
the quality of all of the code.

I think that we should:
 - continue with 1.4-M2
 - create a wiki page where we can get one master list of  things we like
and don't like
 - see what we can do to address those

We're really not getting anywhere with this conversation until we have a
finite list, and some options for each con on the list.  Then we can either
choose the best options or say forget it.


I agree with the above points.

Furthermore, we're not really getting any idea about how the community 
feels about generics. A vocal minority speaks up. On the list, things 
tend to be biased towards the problems and not the things working well 
(the people happily going about their business without issues are less 
likely to be reading along and posting their experiences).


There were about 100 votes +1 *quick* generic release and I don't see 
very many complaints. Why not wait a bit, polish some of the rough edges 
and have a poll or something to ask the community how they feel...


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread James Carman

Well, perhaps if we documented our specific usecases, it might help
the case for change (that's assuming there aren't already a million
other people doing the same thing ;).  I think creating the Wiki is a
good idea.  It will help us identify the growing pains we're facing
and perhaps let folks propose solutions.  Or, if the growing pains are
too numerous (which could very well be the case), we may decide that
it's just not worth it.


On Thu, May 22, 2008 at 10:42 AM, Jonathan Locke
[EMAIL PROTECTED] wrote:

 Yes. I think trying to fix this problem is really trying to fix Java, which
 is pretty far outside our scope. Sun Microsystems should be trying to fix
 such use cases not us. If people are leaving the Java platform because of
 verbosity my guess is such people left when they saw their first anonymous
 class, but that's just my opinion.

 In the case at hand, if we're doing generics where it's an unreasonable use
 case, that's one thing. We can fix that. But I think a class like component
 is almost certainly a reasonable use case and if we can't come to an
 agreement to make that generic, there's something more deeply wrong with
 Java generics which we can't fix and so the only reasonable course of action
 at that point is to scrap generics entirely  for now and wait for Sun
 Microsystems to fix it (which is the reason I asked if we could not create a
 version with the generics removed). Personally, I don't see this use of Void
 as something even remotely close to a reason to scrap it. I would happily
 use that construct every day. But that's just me.


 Sebastiaan van Erk wrote:

 Jan Kriesten wrote:

 hi johan,

 But if you have a lot of LinkVoid for you cases
 then make 1 simple subclass of Link

 so anyone make your own wrapper to get readable sources again? let me
 think: how many webmarkupcontainer, link, page etc. classes do i use
 with void?

 i don't think that's a serious option.

 While LinkVoid is somewhat more verbose than Link, I seriously think
 that people are making too big a deal out of it. Is LinkVoid really
 that unreadable? Is it really that hard to code? Personally I think
 *adds* to the clarity; it says you're not going to use the model of the
 Link component.

 Regards,
 Sebastiaan

 --- jan.



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





 --
 View this message in context: 
 http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17405816.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: (Class? extends Page?) casting troubles

2008-05-22 Thread Jonathan Locke

Yes. I think trying to fix this problem is really trying to fix Java, which
is pretty far outside our scope. Sun Microsystems should be trying to fix
such use cases not us. If people are leaving the Java platform because of
verbosity my guess is such people left when they saw their first anonymous
class, but that's just my opinion.

In the case at hand, if we're doing generics where it's an unreasonable use
case, that's one thing. We can fix that. But I think a class like component
is almost certainly a reasonable use case and if we can't come to an
agreement to make that generic, there's something more deeply wrong with
Java generics which we can't fix and so the only reasonable course of action
at that point is to scrap generics entirely for now and wait for Sun
Microsystems to fix it (which is the reason I asked if we could not create a
version with the generics removed). Personally, I don't see this use of Void
as something even remotely close to a reason to scrap it. I would happily
use that construct every day. But that's just me.

Sebastiaan van Erk wrote:

Jan Kriesten wrote:

hi johan,

But if you have a lot of LinkVoid for you cases
then make 1 simple subclass of Link

so anyone make your own wrapper to get readable sources again? let me
think: how many webmarkupcontainer, link, page etc. classes do i use
with void?

i don't think that's a serious option.

While LinkVoid is somewhat more verbose than Link, I seriously think
that people are making too big a deal out of it. Is LinkVoid really
that unreadable? Is it really that hard to code? Personally I think
*adds* to the clarity; it says you're not going to use the model of the
Link component.

Regards,
Sebastiaan

--- jan.

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

--
View this message in context:
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17405816.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: (Class? extends Page?) casting troubles

2008-05-22 Thread Doug Donohoe


I'll chime in again.  I really like generics.   When I first upgraded to 1.4,
I did a bit of grumbling, but I came to realize some great benefits,
especially with components.  I'd hate to lose that (almost as much as I'd
hate to go through my whole code base and remove that work).

I did a couple of things that made things easier.  First, all my pages
subclassed from a common ancestor which I just changed to 'extends
WebPageVoid'.  Second, I created some utility classes such as

   VoidContainer extends WebMarkupContainerVoid
   StringLabel extends LabelString

and so on.  I don't feel that having to create these utility classes is a
hassle or is a mark against the API.  Rather, it helps me understand how and
where I use certain types of components.  It also helps with refactoring.  

There is one place that it is ugly, but it is an edge case in a logout link. 
I just used @SuppressWarnings to deal with it.

@SuppressWarnings({unchecked})
@Override
public void onClick()
{
getSession().invalidate();
// need to use class so page is created new
setResponsePage((Classlt;? extends Pagelt;?)
getPage().getClass()));
}

The bottom line was that the work didn't take that long and in the end I
feel my code is more readable and type-safe.

-Doug


Jeremy Thomerson-5 wrote:
 
 I haven't said anything up to this point, but we really don't seem to be
 getting anywhere with what is turning into a religious war.  I, for one,
 have already started using 1.4, and love the generics, despite the extra
 verbosity.  It gives me extra type safety and code self-documentation.  I
 would be very against having the framework do a cast as has been suggested
 on here, because that is a hack, and not useful for anything - I lose the
 value of generics because the compiler is no longer checking my type
 safety
 throughout the application.  If I came to a framework without previous
 experience with it, and discovered that ugly hack, I would be worried
 about
 the quality of all of the code.
 
 I think that we should:
  - continue with 1.4-M2
  - create a wiki page where we can get one master list of  things we like
 and don't like
  - see what we can do to address those
 
 We're really not getting anywhere with this conversation until we have a
 finite list, and some options for each con on the list.  Then we can
 either
 choose the best options or say forget it.
 
 -- 
 Jeremy Thomerson
 http://www.wickettraining.com
 
 On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten [EMAIL PROTECTED]
 wrote:
 

 hi sebastiaan,

  I'm very much against using generics to do something other from what
 generics where meant to do (i.e., type safety).


 i'm all in when you're talking about type safety. having compile-time
 checks on the types is a time-saver during development.

 with wicket generics it's just that the time-saver get's in it's own way,
 i.e. bringing in so much boilerplate, that coding is getting harder to do
 right (besides from source readability).


 regards, --- jan.

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


 
 

-- 
View this message in context: 
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17406422.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: (Class? extends Page?) casting troubles

2008-05-22 Thread Igor Vaynberg

actually, if implemented properly EditPage should take IModelPerson
and not Person itself. so unless you typed Link you have IModel?
that you have to cast to IModelPerson

-igor

On Thu, May 22, 2008 at 2:45 AM, Jan Kriesten [EMAIL PROTECTED] wrote:

 Hi Johan,

 I thing that the example below is exactly the thing that generics are
 pretty
 good:

 populateItem(ListItemPerson item) {
   add(new LinkPerson(edit, item.getModel()) {
   public void onClick() {
   setResponsePage(new EditPage(getModelObject()));
   }
   });

 (and EditPage is by itself already generified to Person)

 well, just that the LinkPerson is IMHO redundant and unnecessary(just
 dropped a note to Martijn, but since you brought that up...)

 populateItem(final ListItemPerson item) {
item.add(new Link(edit) {
public void onClick() {
setResponsePage(new EditPage(item.getModelObject()));
}
});

 So, it might have sense with ListItem, but not necissarily with Link...

 Regards, --- Jan.



 -
 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: (Class? extends Page?) casting troubles



Hi Doug,

 The bottom line was that the work didn't take that long and in the end I
 feel my code is more readable and type-safe.

I have tried 4 times to convert my 1.3 codebase to 1.4 - and failed 4 times. All 
in all I spent 3 days and just reverted it.


There are API changes thru generics, which just break the way my app works.

Trying to code tables with PropertyColumns and IColumns just isn't readable any 
more due to having to cast (which before wasn't necessary)...


And the many Void aren't making it any better of course!


Best regards, --- Jan.

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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Martijn Dashorst

Since I like to have the last word in all discussions, let's close
this one down and move it to our development list. I have started a
[discuss] thread over there with an outline of a process. See you
there!

Martijn

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

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Gerolf Seitz

Eelco,
can you try it again with latest trunk?

Cheers,
  Gerolf

On Wed, May 21, 2008 at 6:54 AM, Eelco Hillenius [EMAIL PROTECTED]
wrote:

 On Tue, May 20, 2008 at 9:44 PM, Gerolf Seitz [EMAIL PROTECTED]
 wrote:
  i have the fix for that in my local checkout and
  will commit it sometime today.

 Cool. I just found out Wicket In Action's code
 (http://code.google.com/p/wicketinaction/) had compile errors.
 Ideally, Wicket 1.4 it should be completely backwards compatible.

 A copy from the errors Eclipse reports:

 The constructor
 RestartResponseAtInterceptPageException(ClassSigninPage) is
 undefined
 book-wicket-in-action/src/java/wicket/in/action/chapter12/authdiscounts
 UserPanel.java  line
 37  1211331768935   213000
 The constructor
 RestartResponseAtInterceptPageException(ClassSigninPage) is
 undefined
 book-wicket-in-action/src/java/wicket/in/action/chapter13/locdiscounts
  UserPanel.java  line
 41  1211331768461   212926
 The constructor
 RestartResponseAtInterceptPageException(ClassSigninPage) is
 undefined   book-wicket-in-action/src/java/wicket/in/action/common
  WiaAuthorizationStrategy.java   line
 36  1211331766706   212722
 The method setModelObject(capture#6-of ?) in the type
 Componentcapture#6-of ? is not applicable for the arguments
 (int)
 book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_1
  HelloWorldTest.java line
 91  1211331768160   212829
 The method setObject(Object) of type CheeseModel must override a
 superclass method
 book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3
 Index.java  line
 42  1211331769904   213426
 The method startPanel(TestPanelSource) in the type BaseWicketTester is
 not applicable for the arguments
 (ClassHelloWorldPanel)
  book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_1
  HelloWorldTest.java line
 66  1211331768160   212828
 The return type is incompatible with
 Application.getHomePage()
 book-wicket-in-action/src/java/wicket/in/action
 WicketInActionApplication.java  line
 125 1211331770166   213591
 The return type is incompatible with
 MarkupContainer.setModel(IModel)
  book-wicket-in-action/src/java/wicket/in/action/common
  AjaxEditableLabel.java  line
 129 1211331767509   212759
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_2
 Index.java  line
 61  1211331769986   213564
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3
 Index.java  line
 61  1211331769970   213527
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3
 ShoppingCartPanel.java  line
 32  1211331769946   213506
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_2
 Index.java  line
 120 1211331769917   213443
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3
 Index.java  line
 29  1211331769904   213425
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_3
  Index.java  line
 113 1211331767771   212812
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_3
  Index.java  line
 132 1211331767771   212815


 Eelco

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

Re: (Class? extends Page?) casting troubles

always strange that that works
If you just look at it then it seems to be the same thing :)

i already did those changes for IVisitor, from

public final Object visitChildren(final Class? clazz,
final IVisitor? extends Component? visitor)
to this i believe.

public final S extends Component? Object visitChildren(final Class?
clazz,
final IVisitorS visitor)

But i guess it is all in when the check is done

On Wed, May 21, 2008 at 9:19 AM, Gerolf Seitz [EMAIL PROTECTED]
wrote:

 Eelco,
 can you try it again with latest trunk?

 Cheers,
  Gerolf

 On Wed, May 21, 2008 at 6:54 AM, Eelco Hillenius 
 [EMAIL PROTECTED]
 wrote:

  On Tue, May 20, 2008 at 9:44 PM, Gerolf Seitz [EMAIL PROTECTED]
  wrote:
   i have the fix for that in my local checkout and
   will commit it sometime today.
 
  Cool. I just found out Wicket In Action's code
  (http://code.google.com/p/wicketinaction/) had compile errors.
  Ideally, Wicket 1.4 it should be completely backwards compatible.
 
  A copy from the errors Eclipse reports:
 
  The constructor
  RestartResponseAtInterceptPageException(ClassSigninPage) is
  undefined
  book-wicket-in-action/src/java/wicket/in/action/chapter12/authdiscounts
  UserPanel.java  line
  37  1211331768935   213000
  The constructor
  RestartResponseAtInterceptPageException(ClassSigninPage) is
  undefined
  book-wicket-in-action/src/java/wicket/in/action/chapter13/locdiscounts
   UserPanel.java  line
  41  1211331768461   212926
  The constructor
  RestartResponseAtInterceptPageException(ClassSigninPage) is
  undefined   book-wicket-in-action/src/java/wicket/in/action/common
   WiaAuthorizationStrategy.java   line
  36  1211331766706   212722
  The method setModelObject(capture#6-of ?) in the type
  Componentcapture#6-of ? is not applicable for the arguments
  (int)
  book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_1
   HelloWorldTest.java line
  91  1211331768160   212829
  The method setObject(Object) of type CheeseModel must override a
  superclass method
  book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3
  Index.java  line
  42  1211331769904   213426
  The method startPanel(TestPanelSource) in the type BaseWicketTester is
  not applicable for the arguments
  (ClassHelloWorldPanel)
   book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_1
   HelloWorldTest.java line
  66  1211331768160   212828
  The return type is incompatible with
  Application.getHomePage()
  book-wicket-in-action/src/java/wicket/in/action
  WicketInActionApplication.java  line
  125 1211331770166   213591
  The return type is incompatible with
  MarkupContainer.setModel(IModel)
   book-wicket-in-action/src/java/wicket/in/action/common
   AjaxEditableLabel.java  line
  129 1211331767509   212759
  The return type is incompatible with
  Model.getObject()
  book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_2
  Index.java  line
  61  1211331769986   213564
  The return type is incompatible with
  Model.getObject()
  book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3
  Index.java  line
  61  1211331769970   213527
  The return type is incompatible with
  Model.getObject()
  book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3
  ShoppingCartPanel.java  line
  32  1211331769946   213506
  The return type is incompatible with
  Model.getObject()
  book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_2
  Index.java  line
  120 1211331769917   213443
  The return type is incompatible with
  Model.getObject()
  book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3
  Index.java  line
  29  1211331769904   213425
  The return type is incompatible with
  Model.getObject()
  book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_3
   Index.java  line
  113 1211331767771   212812
  The return type is incompatible with
  Model.getObject()
  book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_3
   Index.java  line
  132 1211331767771   212815
 
 
  Eelco
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Gerolf Seitz

On Wed, May 21, 2008 at 10:30 AM, Johan Compagner [EMAIL PROTECTED]
wrote:

 always strange that that works
 If you just look at it then it seems to be the same thing :)


tbh, i would still like to get an explanation _why_ it works with
S extends Component? and not directly with ? extends Component?.

  Gerolf

Re: (Class? extends Page?) casting troubles

Am I the only one who gets confused with all those ? Can't we just
drop the component generification? I see a lot of problems and type
duplication for little gain. I think having IModel generified is a
good thing because it allows you to specify types on your component
constructors.

Martijn

On Wed, May 21, 2008 at 10:38 AM, Gerolf Seitz [EMAIL PROTECTED] wrote:
 On Wed, May 21, 2008 at 10:30 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:

 always strange that that works
 If you just look at it then it seems to be the same thing :)


 tbh, i would still like to get an explanation _why_ it works with
 S extends Component? and not directly with ? extends Component?.

  Gerolf




-- 
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: (Class? extends Page?) casting troubles

2008-05-21 Thread Timo Rantalaiho

On Wed, 21 May 2008, Martijn Dashorst wrote:
 Am I the only one who gets confused with all those ? Can't we just
 drop the component generification? I see a lot of problems and type
 duplication for little gain. I think having IModel generified is a
 good thing because it allows you to specify types on your component
 constructors.

+1

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

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

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Wouter Huijnink



Am I the only one who gets confused with all those ? 


you are not!


Can't we just
drop the component generification? I see a lot of problems and type
duplication for little gain. I think having IModel generified is a
good thing because it allows you to specify types on your component
constructors.
  


I fully agree. When even Pages get generified, I think the reuse of 
markup will be severely compromised, for instance. Because either all 
page models need to extend from the base page's Model, or you need to 
explicate that you consider your page modelless by using the Void type (?)


Please, please reconsider the design decisions and make explicit:
 - what is the purpose of Model generification?
 - what is the purpose of Component generification?
 - what is the impact of Component generification?

I sometimes get the feeling that there is no 'grand view' on 
generification, but that the operation just took off and now all kinds 
of generic propagations are implemented in an ad hoc fashion...



regards,
Wouter

--
Wouter Huijnink
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500


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

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Peter Ertl

I suspect the multiple wildcards (?) in one type expression causing  
all that trouble.


probably an issue of the compiler and not of the language spec.

public class Test
{
  public static void main(String[] args)
  {
bad(Derived.class); // ok
bad(Base.class); // compile error
good(Derived.class); // ok
good(Base.class); // ok
  }

  public static void bad(Class? extends Base? clazz)
  { //  ^^ two wildcards in one expression:
// uh oh, calling for trouble!
  }

  public static X extends Base? void good(ClassX clazz)
  {
//
  }

  public static class BaseT
  {
  }

  public static class Derived extends BaseVoid
  {
  }
}








Am 21.05.2008 um 10:38 schrieb Gerolf Seitz:

On Wed, May 21, 2008 at 10:30 AM, Johan Compagner [EMAIL PROTECTED] 


wrote:


always strange that that works
If you just look at it then it seems to be the same thing :)



tbh, i would still like to get an explanation _why_ it works with
S extends Component? and not directly with ? extends Component? 
.


 Gerolf

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Peter Ertl


Also if you use CompoundPropertyModels (widely used) then generics are
completely not used anymore at all..


Speaking for me, I never use expression based property models in any  
mid- to large-sized project to have complete(!) refactoring support in  
my IDE.


String expression are a lot less verbose than static bindings, that  
true.


But once I rename a bean property that get's accessed in a component  
or page the change will not affect the string expression of  
PropertyModels and friends. So there will be nice runtime errors.  
Static binding is your friend here.


So I favor for keeping generics (even though it hurts sometimes).

Cheers
Peter


Am 21.05.2008 um 11:03 schrieb Johan Compagner:


if we drop that then we can pretty much drop also model
Because the model goes into the Component and gone is the generified  
model.

Also if you use CompoundPropertyModels (widely used) then generics are
completely not used anymore at all..

So what do we gain then?

For example the DropDownChoice that is generified now makes sure  
that i have

a lot less explaining to on this list..

On Wed, May 21, 2008 at 10:54 AM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:


Am I the only one who gets confused with all those ? Can't we just
drop the component generification? I see a lot of problems and type
duplication for little gain. I think having IModel generified is a
good thing because it allows you to specify types on your component
constructors.

Martijn

On Wed, May 21, 2008 at 10:38 AM, Gerolf Seitz [EMAIL PROTECTED] 


wrote:
On Wed, May 21, 2008 at 10:30 AM, Johan Compagner [EMAIL PROTECTED] 


wrote:


always strange that that works
If you just look at it then it seems to be the same thing :)



tbh, i would still like to get an explanation _why_ it works with
S extends Component? and not directly with ? extends  
Component?.


Gerolf





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





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

Re: (Class? extends Page?) casting troubles

On Wed, May 21, 2008 at 11:03 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 if we drop that then we can pretty much drop also model

Not sure. I think having Component(String id, IModelT model) is a
good thing. However, generifying Component further to get rid of the
cast when doing getModelObject() or getModel() turns out not to be
great.

 Because the model goes into the Component and gone is the generified model.

I don't have a direct problem with that. The generics of Component are
really hard on the eye and the brain. We are trying to make things
simpler and clearer. Having Component(String id, IModelT model)
makes things clearer.

 For example the DropDownChoice that is generified now makes sure that i have
 a lot less explaining to on this list..

Yes, I am not in favor of dropping DDC(String, IModelT,
IModelList? extends T). I am in favor of dropping the generics
from the Component class definition.


Martijn

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

Re: (Class? extends Page?) casting troubles

if we drop that then we can pretty much drop also model
Because the model goes into the Component and gone is the generified model.
Also if you use CompoundPropertyModels (widely used) then generics are
completely not used anymore at all..

So what do we gain then?

For example the DropDownChoice that is generified now makes sure that i have
a lot less explaining to on this list..

On Wed, May 21, 2008 at 10:54 AM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 Am I the only one who gets confused with all those ? Can't we just
 drop the component generification? I see a lot of problems and type
 duplication for little gain. I think having IModel generified is a
 good thing because it allows you to specify types on your component
 constructors.

 Martijn

 On Wed, May 21, 2008 at 10:38 AM, Gerolf Seitz [EMAIL PROTECTED]
 wrote:
  On Wed, May 21, 2008 at 10:30 AM, Johan Compagner [EMAIL PROTECTED]
  wrote:
 
  always strange that that works
  If you just look at it then it seems to be the same thing :)
 
 
  tbh, i would still like to get an explanation _why_ it works with
  S extends Component? and not directly with ? extends Component?.
 
   Gerolf
 



 --
 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: (Class? extends Page?) casting troubles

2008-05-21 Thread Peter Ertl


Maybe this can help a little:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6384510
(verified with java 1.5 on mac os x leopard)


Am 21.05.2008 um 11:13 schrieb Martijn Dashorst:

On Wed, May 21, 2008 at 11:03 AM, Johan Compagner [EMAIL PROTECTED] 
 wrote:

if we drop that then we can pretty much drop also model


Not sure. I think having Component(String id, IModelT model) is a
good thing. However, generifying Component further to get rid of the
cast when doing getModelObject() or getModel() turns out not to be
great.

Because the model goes into the Component and gone is the  
generified model.


I don't have a direct problem with that. The generics of Component are
really hard on the eye and the brain. We are trying to make things
simpler and clearer. Having Component(String id, IModelT model)
makes things clearer.

For example the DropDownChoice that is generified now makes sure  
that i have

a lot less explaining to on this list..


Yes, I am not in favor of dropping DDC(String, IModelT,
IModelList? extends T). I am in favor of dropping the generics
from the Component class definition.


Martijn

-
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: (Class? extends Page?) casting troubles

and both compilers Eclipse and Javac both report the problem?

What happens if if we say ? then raw types are not allowed anymore
At least that is what sun says and also wants..
So i get ? extends Component? that that gives a compile error if you
give a Component that is of raw type

But why is it that if you do C extends Component? xxxC why it then
suddenly does compile
thats just weird..

johan


On Wed, May 21, 2008 at 11:03 AM, Peter Ertl [EMAIL PROTECTED] wrote:

 I suspect the multiple wildcards (?) in one type expression causing all
 that trouble.

 probably an issue of the compiler and not of the language spec.

 public class Test
 {
  public static void main(String[] args)
  {
bad(Derived.class); // ok
bad(Base.class); // compile error
good(Derived.class); // ok
good(Base.class); // ok
  }

  public static void bad(Class? extends Base? clazz)
  { //  ^^ two wildcards in one expression:
// uh oh, calling for trouble!
  }

  public static X extends Base? void good(ClassX clazz)
  {
//
  }

  public static class BaseT
  {
  }

  public static class Derived extends BaseVoid
  {
  }
 }








 Am 21.05.2008 um 10:38 schrieb Gerolf Seitz:


  On Wed, May 21, 2008 at 10:30 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:

  always strange that that works
 If you just look at it then it seems to be the same thing :)


 tbh, i would still like to get an explanation _why_ it works with
 S extends Component? and not directly with ? extends Component?.

  Gerolf

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Wouter Huijnink


Martijn Dashorst wrote:

That is not my problem. The problem is that ComponentT is confusing
as hell and opens up the box of pandorra wrt generics. I *like*
IModelT but I fail to see how setResponsePage(? extends ? extends
?) is necessary for this. The only reason iirc to generify
component is to remove the casts for these two methods:

IModel getModel()
Object getModelObject()

I can live with having these methods not being generified.
  


+1

--
Wouter Huijnink
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500


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

Re: (Class? extends Page?) casting troubles

That is not my problem. The problem is that ComponentT is confusing
as hell and opens up the box of pandorra wrt generics. I *like*
IModelT but I fail to see how setResponsePage(? extends ? extends
?) is necessary for this. The only reason iirc to generify
component is to remove the casts for these two methods:

IModel getModel()
Object getModelObject()

I can live with having these methods not being generified.

Martijn

On Wed, May 21, 2008 at 11:36 AM, Peter Ertl [EMAIL PROTECTED] wrote:
 Maybe this can help a little:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6384510
 (verified with java 1.5 on mac os x leopard)


 Am 21.05.2008 um 11:13 schrieb Martijn Dashorst:

 On Wed, May 21, 2008 at 11:03 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:

 if we drop that then we can pretty much drop also model

 Not sure. I think having Component(String id, IModelT model) is a
 good thing. However, generifying Component further to get rid of the
 cast when doing getModelObject() or getModel() turns out not to be
 great.

 Because the model goes into the Component and gone is the generified
 model.

 I don't have a direct problem with that. The generics of Component are
 really hard on the eye and the brain. We are trying to make things
 simpler and clearer. Having Component(String id, IModelT model)
 makes things clearer.

 For example the DropDownChoice that is generified now makes sure that i
 have
 a lot less explaining to on this list..

 Yes, I am not in favor of dropping DDC(String, IModelT,
 IModelList? extends T). I am in favor of dropping the generics
 from the Component class definition.


 Martijn

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





-- 
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: (Class? extends Page?) casting troubles

as i said. any generified use of CompoundPropertyModel is gone

Also if you make getModel() return a normal IModel that is of raw type i
think you get warnings everywhere again...
and i think only suppresswarnings will help those
Because if yo do

IModelString stringModel = (IModelString)component.getModel();

that will generate a warning as far as i know.
and i guess if you dont cast:

IModel stringModel = component.getModel();

will also generate a warning? i am not sure because i see so many. But there
you use IModel that is a generic type as a raw type..

i still think dropping it from component we could drop it also from model
Because the only thing we gain that is that for a few classes the Api is
more clear (DropDown and ListView)
But for the rest it doesnt bring almost anything. No type safety pretty much
anywhere.

johan





On Wed, May 21, 2008 at 11:53 AM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 That is not my problem. The problem is that ComponentT is confusing
 as hell and opens up the box of pandorra wrt generics. I *like*
 IModelT but I fail to see how setResponsePage(? extends ? extends
 ?) is necessary for this. The only reason iirc to generify
 component is to remove the casts for these two methods:

 IModel getModel()
 Object getModelObject()

 I can live with having these methods not being generified.

 Martijn

 On Wed, May 21, 2008 at 11:36 AM, Peter Ertl [EMAIL PROTECTED] wrote:
  Maybe this can help a little:
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6384510
  (verified with java 1.5 on mac os x leopard)
 
 
  Am 21.05.2008 um 11:13 schrieb Martijn Dashorst:
 
  On Wed, May 21, 2008 at 11:03 AM, Johan Compagner [EMAIL PROTECTED]
 
  wrote:
 
  if we drop that then we can pretty much drop also model
 
  Not sure. I think having Component(String id, IModelT model) is a
  good thing. However, generifying Component further to get rid of the
  cast when doing getModelObject() or getModel() turns out not to be
  great.
 
  Because the model goes into the Component and gone is the generified
  model.
 
  I don't have a direct problem with that. The generics of Component are
  really hard on the eye and the brain. We are trying to make things
  simpler and clearer. Having Component(String id, IModelT model)
  makes things clearer.
 
  For example the DropDownChoice that is generified now makes sure that i
  have
  a lot less explaining to on this list..
 
  Yes, I am not in favor of dropping DDC(String, IModelT,
  IModelList? extends T). I am in favor of dropping the generics
  from the Component class definition.
 
 
  Martijn
 
  -
  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]
 
 



 --
 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: (Class? extends Page?) casting troubles

2008-05-21 Thread Jan Kriesten



Hi,


IModel getModel()
Object getModelObject()
I can live with having these methods not being generified.


for my own cases, generics have been also been more pain- than helpful with 
Wicket.

I don't see any _real_ advantage in having all components needing a type just 
for the sake of typing IModel.


Isn't there an alternative approach? I'd suggest moving to scala - but that's no 
 real option I suppose... ;-) Else one could just externalize the Model 
handling out of Component into a Trait which could be generified. For Java 
actually I have no idea how that could be accomplished for Wicket...


Best regards, --- Jan.



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

Re: (Class? extends Page?) casting troubles


Martijn Dashorst wrote:

That is not my problem. The problem is that ComponentT is confusing
as hell and opens up the box of pandorra wrt generics. I *like*
IModelT but I fail to see how setResponsePage(? extends ? extends
?) is necessary for this. The only reason iirc to generify
component is to remove the casts for these two methods:

IModel getModel()
Object getModelObject()

I can live with having these methods not being generified.

Martijn


Ugh,

-1 (nonbinding of course ;-)) for me on that.

Almost all accesses to the model objects or models are via Component. If 
that one is gone, then in my opinion you might as well get rid of the 
IModel generics as well.


Plus as Johan said, with a half/half IModel-only approach you'll really 
have bunches of warnings to suppress.


Generics are hard, especially for library/framework designers: it's hard 
to get them exactly right, especially with wildcards in complex cases. 
But just because they are not currently exactly right yet in M1 seems no 
reason to throw them all overboard again...


Regards,
Sebastiaan




On Wed, May 21, 2008 at 11:36 AM, Peter Ertl [EMAIL PROTECTED] wrote:

Maybe this can help a little:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6384510
(verified with java 1.5 on mac os x leopard)


Am 21.05.2008 um 11:13 schrieb Martijn Dashorst:


On Wed, May 21, 2008 at 11:03 AM, Johan Compagner [EMAIL PROTECTED]
wrote:

if we drop that then we can pretty much drop also model

Not sure. I think having Component(String id, IModelT model) is a
good thing. However, generifying Component further to get rid of the
cast when doing getModelObject() or getModel() turns out not to be
great.


Because the model goes into the Component and gone is the generified
model.

I don't have a direct problem with that. The generics of Component are
really hard on the eye and the brain. We are trying to make things
simpler and clearer. Having Component(String id, IModelT model)
makes things clearer.


For example the DropDownChoice that is generified now makes sure that i
have
a lot less explaining to on this list..

Yes, I am not in favor of dropping DDC(String, IModelT,
IModelList? extends T). I am in favor of dropping the generics
from the Component class definition.


Martijn

-
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: (Class? extends Page?) casting troubles

On Wed, May 21, 2008 at 2:19 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 Generics are hard, especially for library/framework designers: it's hard to
 get them exactly right, especially with wildcards in complex cases. But just
 because they are not currently exactly right yet in M1 seems no reason to
 throw them all overboard again...

Not only for framework designers. *I* as a user of Wicket don't know
how to perform a setResponsePage() with the above code. This is not a
problem for framework designers. This is generics getting out of
control.

They make my code unreadable, hence unmaintainable. There is little
benefit of removing those 2 casts (where I never have had any
problems) compared to the UGLY stick that generified component smacks
on my code.

Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.

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

Re: (Class? extends Page?) casting troubles


Martijn Dashorst wrote:

On Wed, May 21, 2008 at 2:19 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Generics are hard, especially for library/framework designers: it's hard to
get them exactly right, especially with wildcards in complex cases. But just
because they are not currently exactly right yet in M1 seems no reason to
throw them all overboard again...


Not only for framework designers. *I* as a user of Wicket don't know
how to perform a setResponsePage() with the above code. This is not a
problem for framework designers. This is generics getting out of
control.


Well the fact that setResponsePage doesn't work with just a Page class 
seems to be an issue of the framework not the user (and yes it may be 
caused by an issue with generics, but in the end, the user of the 
framework should just be able to do: setResponsePage(MyPage.class) as 
they always did, and as is logical).



They make my code unreadable, hence unmaintainable. There is little
benefit of removing those 2 casts (where I never have had any
problems) compared to the UGLY stick that generified component smacks
on my code.


I agree that generics are overly verbose sometimes... but they give you 
back extra type safety. I guess whether you like this tradeoff or not is 
a personal choice (I like it, even though I would have preferred less 
verbose code and I hate erasure).



Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.


Yes, but in my opinion rather useless as well. Plus you get heaps of 
@SuppressWarnings all over the place. Then just get rid of generics 
completely...


Regards,
Sebastiaan





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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Doug Donohoe

Having moved my wicket project to the 1.4 trunk, I have to say that I like
generics quite a bit. Yes, there is a bit of a learning curve with them,
but in general I like not having to cast my getModelObject() calls. It is
especially nice inside of DataView and DropDownChoice. Learning curve
problems can be overcome with good examples.

Generics add a lot in type safety and, once you get used to them,
convenience.

I strongly vote against backing out this work.

-Doug

Johan Compagner wrote:

as i said. any generified use of CompoundPropertyModel is gone

Also if you make getModel() return a normal IModel that is of raw type i
think you get warnings everywhere again...
and i think only suppresswarnings will help those
Because if yo do

IModelString stringModel = (IModelString)component.getModel();

that will generate a warning as far as i know.
and i guess if you dont cast:

IModel stringModel = component.getModel();

will also generate a warning? i am not sure because i see so many. But
there
you use IModel that is a generic type as a raw type..

i still think dropping it from component we could drop it also from model
Because the only thing we gain that is that for a few classes the Api is
more clear (DropDown and ListView)
But for the rest it doesnt bring almost anything. No type safety pretty
much
anywhere.

johan

On Wed, May 21, 2008 at 11:53 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:

That is not my problem. The problem is that ComponentT is confusing
as hell and opens up the box of pandorra wrt generics. I *like*
IModelT but I fail to see how setResponsePage(? extends ? extends
?) is necessary for this. The only reason iirc to generify
component is to remove the casts for these two methods:

IModel getModel()
Object getModelObject()

I can live with having these methods not being generified.

Martijn

On Wed, May 21, 2008 at 11:36 AM, Peter Ertl [EMAIL PROTECTED] wrote:
Maybe this can help a little:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6384510
(verified with java 1.5 on mac os x leopard)

Am 21.05.2008 um 11:13 schrieb Martijn Dashorst:

On Wed, May 21, 2008 at 11:03 AM, Johan Compagner
[EMAIL PROTECTED]

wrote:

if we drop that then we can pretty much drop also model

Not sure. I think having Component(String id, IModelT model) is a
good thing. However, generifying Component further to get rid of the
cast when doing getModelObject() or getModel() turns out not to be
great.

Because the model goes into the Component and gone is the generified
model.

I don't have a direct problem with that. The generics of Component are
really hard on the eye and the brain. We are trying to make things
simpler and clearer. Having Component(String id, IModelT model)
makes things clearer.

For example the DropDownChoice that is generified now makes sure that
i
have
a lot less explaining to on this list..

Yes, I am not in favor of dropping DDC(String, IModelT,
IModelList? extends T). I am in favor of dropping the generics
from the Component class definition.

Martijn

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

--
View this message in context:
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17364199.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: (Class? extends Page?) casting troubles

On Wed, May 21, 2008 at 2:44 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 Generified component touches *ALL* code in Wicket, wether you care or
 not. IModelT itself is rather contained.
 Yes, but in my opinion rather useless as well. Plus you get heaps of
 @SuppressWarnings all over the place. Then just get rid of generics
 completely...

It is not useless. It *documents* the API in a self describing manner,
without getting out of control, or without having to read fricking
LISP code.

The suppress warnings can be turned off by telling your compiler not to warn.

And why would you need suppress warnings? Not for this:

Link link = new Link(link, personmodel) {
onclick() {
Person p = (Person)getModelObject();
}
};

Not one warning in sight when you use this code. DDC is the same:
barely you need to work directly with its model object, because you
bind it to another object. I have little or no code that does
ddc.getModelObject(); and even then, one cast is enough, and will get
rid of about 100 gazillion repeats of the type parameters.

Typesafety through obscurity is not a direction I want Wicket to go.
It is already hard enough to learn Wicket's basics. With ComponentT
it gets too difficult.

Martijn

-- 
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: (Class? extends Page?) casting troubles

2008-05-21 Thread Joni Freeman


On Wed, 2008-05-21 at 14:44 +0200, Sebastiaan van Erk wrote:
 Martijn Dashorst wrote:
  Generified component touches *ALL* code in Wicket, wether you care or
  not. IModelT itself is rather contained.
 
 Yes, but in my opinion rather useless as well. Plus you get heaps of 
 @SuppressWarnings all over the place. Then just get rid of generics 
 completely...

In which case would you need @SuppressWarnings? Consider for instance:

interface IModelT {
}

class Component {
private IModel? model;

public T IModelT getModel() {
return (IModelT) model;
}
}

class MyComp extends Component {
public MyComp() {
IModelInteger model = getModel();
}
}

This compiles and the only warning is within wicket code. There's an
unsafe cast to IModelT. Of course this would mean that getModel and
getModelObject could throw classcastexception. It's a tradeoff: simple
and more conservative usage of generics vs. fully type safe but complex
and verbose usage of generics.

Joni







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

Re: (Class? extends Page?) casting troubles

I must say if this works, it has my +1000 support.

Martijn

On Wed, May 21, 2008 at 3:01 PM, Joni Freeman [EMAIL PROTECTED] wrote:

 On Wed, 2008-05-21 at 14:44 +0200, Sebastiaan van Erk wrote:
 Martijn Dashorst wrote:
  Generified component touches *ALL* code in Wicket, wether you care or
  not. IModelT itself is rather contained.

 Yes, but in my opinion rather useless as well. Plus you get heaps of
 @SuppressWarnings all over the place. Then just get rid of generics
 completely...

 In which case would you need @SuppressWarnings? Consider for instance:

interface IModelT {
}

class Component {
private IModel? model;

public T IModelT getModel() {
return (IModelT) model;
}
}

class MyComp extends Component {
public MyComp() {
IModelInteger model = getModel();
}
}

 This compiles and the only warning is within wicket code. There's an
 unsafe cast to IModelT. Of course this would mean that getModel and
 getModelObject could throw classcastexception. It's a tradeoff: simple
 and more conservative usage of generics vs. fully type safe but complex
 and verbose usage of generics.

 Joni







 -
 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: (Class? extends Page?) casting troubles


Martijn Dashorst wrote:

On Wed, May 21, 2008 at 2:44 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.

Yes, but in my opinion rather useless as well. Plus you get heaps of
@SuppressWarnings all over the place. Then just get rid of generics
completely...


It is not useless. It *documents* the API in a self describing manner,
without getting out of control, or without having to read fricking
LISP code.


Hmm.. I'm not really sure I find that a good argument. Documentation 
should be done by: 1) javadoc, 2) good naming conventions (IMHO). And 
where would you use the generics of IModel if you can't use getModel() 
on component? If I define a model I'd say:


class PersonModel implements IModelPerson {
}

but after that I'd be using the model with new PersonModel(...) and not 
referring to the generics at all...



The suppress warnings can be turned off by telling your compiler not to warn.


Yes, and that kills all other warnings which you LIKE to have in your 
own and other generics code! And all that to use Wicket without warnings!



And why would you need suppress warnings? Not for this:

Link link = new Link(link, personmodel) {
onclick() {
Person p = (Person)getModelObject();
}
};


You're right, not for that. But as soon as you use getModel() you do. 
Because it returns an IModel (which is a raw type, WARNING). Then you 
want to cast the model back to something useful (unchecked conversion, 
WARNING).



Typesafety through obscurity is not a direction I want Wicket to go.
It is already hard enough to learn Wicket's basics. With ComponentT
it gets too difficult.


Well I can't argue with where you want Wicket to go. :-) I like the 
generics, and have no problems with a few rough edges in M1. But I can 
understand that some people find it overly complex or verbose, and they 
are entitled to their opinions of course. If you guys decide to drop 
generics again, then I'll still use Wicket happily...


But please no half/half and forced turning of generics warnings to be 
able to use the framework properly!! :-)



Martijn


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles


Joni Freeman wrote:

On Wed, 2008-05-21 at 14:44 +0200, Sebastiaan van Erk wrote:

Martijn Dashorst wrote:

Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.
Yes, but in my opinion rather useless as well. Plus you get heaps of 
@SuppressWarnings all over the place. Then just get rid of generics 
completely...


In which case would you need @SuppressWarnings? Consider for instance:

interface IModelT {
}

class Component {

private IModel? model;

public T IModelT getModel() {
return (IModelT) model;
}
}

class MyComp extends Component {

public MyComp() {
IModelInteger model = getModel();
}
}

This compiles and the only warning is within wicket code. There's an
unsafe cast to IModelT. Of course this would mean that getModel and
getModelObject could throw classcastexception. It's a tradeoff: simple
and more conservative usage of generics vs. fully type safe but complex
and verbose usage of generics.

Joni


That's pretty ok I guess, hadn't though of that. Better than returning a 
raw IModel. :-)


Does this always work nicely though, because you need to do a capture 
which means that the compiler must be able to infer the type... I've had 
problems before in these kind of situations that for me it seems 
obvious, but the compiler gives me an error and says it doesn't know 
what the type should be...


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Ryan McKinley


does this mean it should work now?

strangely, things work fine for me in eclipse, but from the command  
line, I still get:


$ mvn clean install:

/Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/ 
wicket/page/DownloadingPage.java:[18,97] inconvertible types
found   :  
java.lang.Classdexter.website.wicket.page.account.DexSignInPage

required: java.lang.Class? extends org.apache.wicket.Page?

I ran: mvn clean install in the wicket directory...

Not sure if the java version is helpful:
ryan$ mvn -version
Maven version: 2.0.6
ryan$ javac -version
javac 1.6.0_04-dp

thanks for any pointers



On May 21, 2008, at 3:19 AM, Gerolf Seitz wrote:

Eelco,
can you try it again with latest trunk?

Cheers,
 Gerolf

On Wed, May 21, 2008 at 6:54 AM, Eelco Hillenius [EMAIL PROTECTED] 


wrote:

On Tue, May 20, 2008 at 9:44 PM, Gerolf Seitz  
[EMAIL PROTECTED]

wrote:

i have the fix for that in my local checkout and
will commit it sometime today.


Cool. I just found out Wicket In Action's code
(http://code.google.com/p/wicketinaction/) had compile errors.
Ideally, Wicket 1.4 it should be completely backwards compatible.

A copy from the errors Eclipse reports:

The constructor
RestartResponseAtInterceptPageException(ClassSigninPage) is
undefined
book-wicket-in-action/src/java/wicket/in/action/chapter12/ 
authdiscounts

UserPanel.java  line
37  1211331768935   213000
The constructor
RestartResponseAtInterceptPageException(ClassSigninPage) is
undefined
book-wicket-in-action/src/java/wicket/in/action/chapter13/ 
locdiscounts

UserPanel.java  line
41  1211331768461   212926
The constructor
RestartResponseAtInterceptPageException(ClassSigninPage) is
undefined   book-wicket-in-action/src/java/wicket/in/action/ 
common

WiaAuthorizationStrategy.java   line
36  1211331766706   212722
The method setModelObject(capture#6-of ?) in the type
Componentcapture#6-of ? is not applicable for the arguments
(int)
book-wicket-in-action/src/java/wicket/in/action/chapter15/ 
section_15_1

HelloWorldTest.java line
91  1211331768160   212829
The method setObject(Object) of type CheeseModel must override a
superclass method
book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3
Index.java  line
42  1211331769904   213426
The method startPanel(TestPanelSource) in the type BaseWicketTester  
is

not applicable for the arguments
(ClassHelloWorldPanel)
book-wicket-in-action/src/java/wicket/in/action/chapter15/ 
section_15_1

HelloWorldTest.java line
66  1211331768160   212828
The return type is incompatible with
Application.getHomePage()
book-wicket-in-action/src/java/wicket/in/action
WicketInActionApplication.java  line
125 1211331770166   213591
The return type is incompatible with
MarkupContainer.setModel(IModel)
book-wicket-in-action/src/java/wicket/in/action/common
AjaxEditableLabel.java  line
129 1211331767509   212759
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_2
Index.java  line
61  1211331769986   213564
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3
Index.java  line
61  1211331769970   213527
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3
ShoppingCartPanel.java  line
32  1211331769946   213506
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_2
Index.java  line
120 1211331769917   213443
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3
Index.java  line
29  1211331769904   213425
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter15/ 
section_15_3

Index.java  line
113 1211331767771   212812
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter15/ 
section_15_3

Index.java  line
132 1211331767771   212815


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: (Class? extends Page?) casting troubles

2008-05-21 Thread Joni Freeman


On Wed, 2008-05-21 at 15:22 +0200, Sebastiaan van Erk wrote:

 Does this always work nicely though, because you need to do a capture 
 which means that the compiler must be able to infer the type... I've had 
 problems before in these kind of situations that for me it seems 
 obvious, but the compiler gives me an error and says it doesn't know 
 what the type should be...

Well, the type inferencer we got with Java 5 is not very smart. For
instance these work:
 
class MyComp extends Component {
public MyComp() {
IModelMapInteger, ListString model = getModel();
}

protected IModelString foo() {
return getModel();
}
}

But this isn't:

class MyComp extends Component {
public MyComp() {
bar(getModel());
}

public void bar(IModelString model) {
}
}

In that case you must extract a local variable...

Joni


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

Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Gerolf Seitz

Ryan,
this is already fixed in trunk and will be included in the rebuilt M2
release.

  Gerolf

On Wed, May 21, 2008 at 3:49 PM, Ryan McKinley [EMAIL PROTECTED] wrote:

 does this mean it should work now?

 strangely, things work fine for me in eclipse, but from the command line, I
 still get:

 $ mvn clean install:

 /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/wicket/page/DownloadingPage.java:[18,97]
 inconvertible types
 found   : java.lang.Classdexter.website.wicket.page.account.DexSignInPage
 required: java.lang.Class? extends org.apache.wicket.Page?

 I ran: mvn clean install in the wicket directory...

 Not sure if the java version is helpful:
 ryan$ mvn -version
 Maven version: 2.0.6
 ryan$ javac -version
 javac 1.6.0_04-dp

 thanks for any pointers




 On May 21, 2008, at 3:19 AM, Gerolf Seitz wrote:

 Eelco,
 can you try it again with latest trunk?

 Cheers,
  Gerolf

 On Wed, May 21, 2008 at 6:54 AM, Eelco Hillenius 
 [EMAIL PROTECTED]
 wrote:

  On Tue, May 20, 2008 at 9:44 PM, Gerolf Seitz [EMAIL PROTECTED]
 wrote:

 i have the fix for that in my local checkout and
 will commit it sometime today.


 Cool. I just found out Wicket In Action's code
 (http://code.google.com/p/wicketinaction/) had compile errors.
 Ideally, Wicket 1.4 it should be completely backwards compatible.

 A copy from the errors Eclipse reports:

 The constructor
 RestartResponseAtInterceptPageException(ClassSigninPage) is
 undefined
 book-wicket-in-action/src/java/wicket/in/action/chapter12/authdiscounts
 UserPanel.java  line
 37  1211331768935   213000
 The constructor
 RestartResponseAtInterceptPageException(ClassSigninPage) is
 undefined
 book-wicket-in-action/src/java/wicket/in/action/chapter13/locdiscounts
 UserPanel.java  line
 41  1211331768461   212926
 The constructor
 RestartResponseAtInterceptPageException(ClassSigninPage) is
 undefined   book-wicket-in-action/src/java/wicket/in/action/common
 WiaAuthorizationStrategy.java   line
 36  1211331766706   212722
 The method setModelObject(capture#6-of ?) in the type
 Componentcapture#6-of ? is not applicable for the arguments
 (int)
 book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_1
 HelloWorldTest.java line
 91  1211331768160   212829
 The method setObject(Object) of type CheeseModel must override a
 superclass method
 book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3
 Index.java  line
 42  1211331769904   213426
 The method startPanel(TestPanelSource) in the type BaseWicketTester is
 not applicable for the arguments
 (ClassHelloWorldPanel)
 book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_1
 HelloWorldTest.java line
 66  1211331768160   212828
 The return type is incompatible with
 Application.getHomePage()
 book-wicket-in-action/src/java/wicket/in/action
 WicketInActionApplication.java  line
 125 1211331770166   213591
 The return type is incompatible with
 MarkupContainer.setModel(IModel)
 book-wicket-in-action/src/java/wicket/in/action/common
 AjaxEditableLabel.java  line
 129 1211331767509   212759
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_2
 Index.java  line
 61  1211331769986   213564
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3
 Index.java  line
 61  1211331769970   213527
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter03/section_3_3
 ShoppingCartPanel.java  line
 32  1211331769946   213506
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_2
 Index.java  line
 120 1211331769917   213443
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter04/section_4_3
 Index.java  line
 29  1211331769904   213425
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_3
 Index.java  line
 113 1211331767771   212812
 The return type is incompatible with
 Model.getObject()
 book-wicket-in-action/src/java/wicket/in/action/chapter15/section_15_3
 Index.java  line
 132 1211331767771   212815


 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: (Class? extends Page?) casting troubles

2008-05-21 Thread Ryan McKinley

The changes to BookmarkablePageLink are working, but not for  
RestartResponseAtInterceptPageException?


It looks like BookmarkablePageLink is:
 new  BookmarkablePageLink(final String id, final ClassC pageClass)

while
 new RestartResponseAtInterceptPageException(
final Class ? extends Page ?  interceptPageClass)

or am i missing something?


On May 21, 2008, at 10:27 AM, Gerolf Seitz wrote:

Ryan,
this is already fixed in trunk and will be included in the rebuilt M2
release.

 Gerolf

On Wed, May 21, 2008 at 3:49 PM, Ryan McKinley [EMAIL PROTECTED]  
wrote:



does this mean it should work now?

strangely, things work fine for me in eclipse, but from the command  
line, I

still get:

$ mvn clean install:

/Users/ryan/Documents/workspace/dexter/website/src/java/dexter/ 
website/wicket/page/DownloadingPage.java:[18,97]

inconvertible types
found   :  
java.lang.Classdexter.website.wicket.page.account.DexSignInPage

required: java.lang.Class? extends org.apache.wicket.Page?

I ran: mvn clean install in the wicket directory...

Not sure if the java version is helpful:
ryan$ mvn -version
Maven version: 2.0.6
ryan$ javac -version
javac 1.6.0_04-dp

thanks for any pointers




On May 21, 2008, at 3:19 AM, Gerolf Seitz wrote:


Eelco,
can you try it again with latest trunk?

Cheers,
Gerolf

On Wed, May 21, 2008 at 6:54 AM, Eelco Hillenius 
[EMAIL PROTECTED]
wrote:

On Tue, May 20, 2008 at 9:44 PM, Gerolf Seitz [EMAIL PROTECTED] 


wrote:


i have the fix for that in my local checkout and
will commit it sometime today.



Cool. I just found out Wicket In Action's code
(http://code.google.com/p/wicketinaction/) had compile errors.
Ideally, Wicket 1.4 it should be completely backwards compatible.

A copy from the errors Eclipse reports:

The constructor
RestartResponseAtInterceptPageException(ClassSigninPage) is
undefined
book-wicket-in-action/src/java/wicket/in/action/chapter12/ 
authdiscounts

UserPanel.java  line
37  1211331768935   213000
The constructor
RestartResponseAtInterceptPageException(ClassSigninPage) is
undefined
book-wicket-in-action/src/java/wicket/in/action/chapter13/ 
locdiscounts

UserPanel.java  line
41  1211331768461   212926
The constructor
RestartResponseAtInterceptPageException(ClassSigninPage) is
undefined   book-wicket-in-action/src/java/wicket/in/action/ 
common

WiaAuthorizationStrategy.java   line
36  1211331766706   212722
The method setModelObject(capture#6-of ?) in the type
Componentcapture#6-of ? is not applicable for the arguments
(int)
book-wicket-in-action/src/java/wicket/in/action/chapter15/ 
section_15_1

HelloWorldTest.java line
91  1211331768160   212829
The method setObject(Object) of type CheeseModel must override a
superclass method
book-wicket-in-action/src/java/wicket/in/action/chapter04/ 
section_4_3

Index.java  line
42  1211331769904   213426
The method startPanel(TestPanelSource) in the type  
BaseWicketTester is

not applicable for the arguments
(ClassHelloWorldPanel)
book-wicket-in-action/src/java/wicket/in/action/chapter15/ 
section_15_1

HelloWorldTest.java line
66  1211331768160   212828
The return type is incompatible with
Application.getHomePage()
book-wicket-in-action/src/java/wicket/in/action
WicketInActionApplication.java  line
125 1211331770166   213591
The return type is incompatible with
MarkupContainer.setModel(IModel)
book-wicket-in-action/src/java/wicket/in/action/common
AjaxEditableLabel.java  line
129 1211331767509   212759
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter03/ 
section_3_2

Index.java  line
61  1211331769986   213564
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter03/ 
section_3_3

Index.java  line
61  1211331769970   213527
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter03/ 
section_3_3

ShoppingCartPanel.java  line
32  1211331769946   213506
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter04/ 
section_4_2

Index.java  line
120 1211331769917   213443
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter04/ 
section_4_3

Index.java  line
29  1211331769904   213425
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter15/ 
section_15_3

Index.java  line
113 1211331767771   212812
The return type is incompatible with
Model.getObject()
book-wicket-in-action/src/java/wicket/in/action/chapter15/ 
section_15_3

Index.java  line
132 1211331767771   212815


Eelco

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

Re: (Class? extends Page?) casting troubles

yes i also thought about some time ago.

But this is not really better... Now without you doing a cast in the code
(so that you know what you are doing)
you suddenly have a class cast exception at some point later on


class MyComp extends Component {
   public MyComp() {
   IModelInteger model = getModel();
   Integer myInt = model.getObject(); // KABOOM

   }

because this thing gives you really a false kind of protection.

This is really an abuse of generics if you ask me..

johan

On Wed, May 21, 2008 at 3:01 PM, Joni Freeman [EMAIL PROTECTED] wrote:


 On Wed, 2008-05-21 at 14:44 +0200, Sebastiaan van Erk wrote:
  Martijn Dashorst wrote:
   Generified component touches *ALL* code in Wicket, wether you care or
   not. IModelT itself is rather contained.
 
  Yes, but in my opinion rather useless as well. Plus you get heaps of
  @SuppressWarnings all over the place. Then just get rid of generics
  completely...

 In which case would you need @SuppressWarnings? Consider for instance:

interface IModelT {
}

class Component {
private IModel? model;

public T IModelT getModel() {
return (IModelT) model;
}
}

class MyComp extends Component {
public MyComp() {
IModelInteger model = getModel();
}
}

 This compiles and the only warning is within wicket code. There's an
 unsafe cast to IModelT. Of course this would mean that getModel and
 getModelObject could throw classcastexception. It's a tradeoff: simple
 and more conservative usage of generics vs. fully type safe but complex
 and verbose usage of generics.

 Joni







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

Re: (Class? extends Page?) casting troubles


Johan Compagner wrote:

yes i also thought about some time ago.

But this is not really better... Now without you doing a cast in the code
(so that you know what you are doing)
you suddenly have a class cast exception at some point later on


class MyComp extends Component {
   public MyComp() {
   IModelInteger model = getModel();
   Integer myInt = model.getObject(); // KABOOM

   }

because this thing gives you really a false kind of protection.

This is really an abuse of generics if you ask me..


When I think about it, I have to agree. You can do ugly stuff like:

IModelInteger x = getModel();
IModelDouble y = getModel();

and it will compile just fine... :-(

I'd rather have no generics than a dirty hack like this.

Regards,
Sebastiaan



johan

On Wed, May 21, 2008 at 3:01 PM, Joni Freeman [EMAIL PROTECTED] wrote:


On Wed, 2008-05-21 at 14:44 +0200, Sebastiaan van Erk wrote:

Martijn Dashorst wrote:

Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.

Yes, but in my opinion rather useless as well. Plus you get heaps of
@SuppressWarnings all over the place. Then just get rid of generics
completely...

In which case would you need @SuppressWarnings? Consider for instance:

   interface IModelT {
   }

   class Component {
   private IModel? model;

   public T IModelT getModel() {
   return (IModelT) model;
   }
   }

   class MyComp extends Component {
   public MyComp() {
   IModelInteger model = getModel();
   }
   }

This compiles and the only warning is within wicket code. There's an
unsafe cast to IModelT. Of course this would mean that getModel and
getModelObject could throw classcastexception. It's a tradeoff: simple
and more conservative usage of generics vs. fully type safe but complex
and verbose usage of generics.

Joni







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






smime.p7s
Description: S/MIME Cryptographic Signature

Re: (Class? extends Page?) casting troubles

Typesafety from getObject() was never the ultimate goal. API clarity
was, and JavaDoc is not API clarity.

Martijn

On Wed, May 21, 2008 at 4:59 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 Johan Compagner wrote:

 yes i also thought about some time ago.

 But this is not really better... Now without you doing a cast in the code
 (so that you know what you are doing)
 you suddenly have a class cast exception at some point later on


 class MyComp extends Component {
   public MyComp() {
   IModelInteger model = getModel();
   Integer myInt = model.getObject(); // KABOOM

   }

 because this thing gives you really a false kind of protection.

 This is really an abuse of generics if you ask me..

 When I think about it, I have to agree. You can do ugly stuff like:

 IModelInteger x = getModel();
 IModelDouble y = getModel();

 and it will compile just fine... :-(

 I'd rather have no generics than a dirty hack like this.

 Regards,
 Sebastiaan


 johan

 On Wed, May 21, 2008 at 3:01 PM, Joni Freeman [EMAIL PROTECTED] wrote:

 On Wed, 2008-05-21 at 14:44 +0200, Sebastiaan van Erk wrote:

 Martijn Dashorst wrote:

 Generified component touches *ALL* code in Wicket, wether you care or
 not. IModelT itself is rather contained.

 Yes, but in my opinion rather useless as well. Plus you get heaps of
 @SuppressWarnings all over the place. Then just get rid of generics
 completely...

 In which case would you need @SuppressWarnings? Consider for instance:

   interface IModelT {
   }

   class Component {
   private IModel? model;

   public T IModelT getModel() {
   return (IModelT) model;
   }
   }

   class MyComp extends Component {
   public MyComp() {
   IModelInteger model = getModel();
   }
   }

 This compiles and the only warning is within wicket code. There's an
 unsafe cast to IModelT. Of course this would mean that getModel and
 getModelObject could throw classcastexception. It's a tradeoff: simple
 and more conservative usage of generics vs. fully type safe but complex
 and verbose usage of generics.

 Joni







 -
 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: (Class? extends Page?) casting troubles

2008-05-21 Thread Zappaterrini, Larry

I think that is only part of the problem in this instance. The other
part of the problem is that Base.class presents only runtime
information. There is no way to invoke Base.Voidclass to get
ClassBaseVoid in a manner similar to how you can invoke a generic
method. The type represented in the  returned by a class literal is
not generic since this information is not present at runtime. Derived
does not have this problem since it is not generic.

I am not completely sure why this plays out the way it does with the
given method signatures, but I have an idea. Derived provides the
reifiable (completely preserved at runtime) type of Void in place of T.
So when the method bad is called with Derived, ? can be inferred to be
of type Void. This is not possible with the generic type Base since T is
not reifiable and not provided by the literal Base.class. The compiler
cannot infer what ? should be. Providing X extends Base? for the
method good circumvents this conundrum. 

Looking at the messages this produces in Eclipse:

bad(Derived.class) displays on hover:
void Test.bad(Class? extends Base? clazz)

bad(Base.class) displays the error:
The method bad(Class? extends Base?) in the 
type Test is not applicable for the  arguments 
(ClassBase)

good(Derived.class) displays on hover
Derived void Test.good(ClassDerived clazz)

good(Base.class) displays on hover
Base void Test.good(ClassBase clazz)

So in the last instance the compiler infers Base for X since Base.class
returns ClassBase and is happy. Changing 

good(ClassX clazz)
to
good(Class? extends X clazz)

Should preserve the original intention of bad(Class? extends Base?
clazz). It is instructive that if you put bad(clazz) as the body of the
method good, everything compiles and runs just fine.

Sorry for the verbosity of this message. I just really wanted to try to
understand this problem and thought that some of you might be interested
in any ideas about it. I have been using the O'Reilly book Java
Generics and Collections as a guide through the murky depths of
generics and it has been most helpful.

-Original Message-
From: Peter Ertl [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 21, 2008 5:04 AM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

I suspect the multiple wildcards (?) in one type expression causing  
all that trouble.

probably an issue of the compiler and not of the language spec.

public class Test
{
   public static void main(String[] args)
   {
 bad(Derived.class); // ok
 bad(Base.class); // compile error
 good(Derived.class); // ok
 good(Base.class); // ok
   }

   public static void bad(Class? extends Base? clazz)
   { //  ^^ two wildcards in one expression:
 // uh oh, calling for trouble!
   }

   public static X extends Base? void good(ClassX clazz)
   {
 //
   }

   public static class BaseT
   {
   }

   public static class Derived extends BaseVoid
   {
   }
}








Am 21.05.2008 um 10:38 schrieb Gerolf Seitz:

 On Wed, May 21, 2008 at 10:30 AM, Johan Compagner
[EMAIL PROTECTED] 
 
 wrote:

 always strange that that works
 If you just look at it then it seems to be the same thing :)


 tbh, i would still like to get an explanation _why_ it works with
 S extends Component? and not directly with ? extends Component? 
 .

  Gerolf

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

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

Re: (Class? extends Page?) casting troubles