is wrong with
ClassFoo clazz = Foo.class?
Cheers,
Larry
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 07, 2008 3:57 AM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles
Zappaterrini, Larry wrote:
Sorry, I should
be parameterized
Regards,
Sebastiaan
Cheers,
Larry
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 07, 2008 3:57 AM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles
Zappaterrini, Larry wrote:
Sorry, I should
: Mon 6/9/2008 12:54 PM
To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles
Zappaterrini, Larry wrote:
Sebastiaan,
Point 1 is a good one. I haven't puzzled that through completely. Upon
initial inspection it seems that it is just the compiler being pedantic
about
[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
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;
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?
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
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
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
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?
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
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
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:
[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
() 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
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
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
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,
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
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 :-)
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
: 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
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
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
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
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
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,
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
+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
+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,
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,
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
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
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
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
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:
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;
}
}
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
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
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
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 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,
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
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
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:
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
+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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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,
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
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.
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?
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
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
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
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
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
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
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
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
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
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
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
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
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 =
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
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
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
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
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
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.
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
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.
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
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
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 :
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
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:
$
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 ?
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() {
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
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
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
Generics is type safety
Not API clarity that was only the case in a few things.
I am against this abuse big time -1000 from me
Then no generics
johan
On Wed, May 21, 2008 at 5:03 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Typesafety from getObject() was never the ultimate goal. API
1 - 100 of 126 matches
Mail list logo
