No. The compiler does not allow. If DropDownChoice is of type ?
extends BaseClass then the problem is that it assumes that
getChoiceRenderer() is also of type ? extends BaseClass. Now at
runtime, because of the wildcard, I do not know what class I have, and
I absolutely cannot use the renderer.
No casting is required. Try this:
BaseClass baseObject = null;
DropDownChoiceBaseClass dropDown = new DropDownChoiceBaseClass(id);
dropDown.getChoiceRenderer().getDisplayValue(null);
This will compile (it won't run because you'll get an NPE if the
display value method doesn't accept null). As
Hi!
Yes.. this is true but not ideally consistent. More consistent would be
DropDownChoice? extends BaseClass dropDown = new DropDownChoice?
extends BaseClass(id);
in such a way that dropDown.getChoiceRenderer() would be automatically
of type BaseClass.
One solution would be to change the
On Sat, Jun 13, 2009 at 8:13 AM, Martin
Makundimartin.maku...@koodaripalvelut.com wrote:
Hi!
Yes.. this is true but not ideally consistent. More consistent would be
DropDownChoice? extends BaseClass dropDown = new DropDownChoice?
extends BaseClass(id);
You can't instantiate with a wildcard
DropDownChoice? extends BaseClass dropDown = new DropDownChoice?
extends BaseClass(id);
You can't instantiate with a wildcard type. That's not allowed by the
Java language.
Ah yes... I'm getting confused myself. So the real problem is that I
instantiate new DropDownChoiceBaseClass(id) but
On Sat, Jun 13, 2009 at 9:25 AM, Martin
Makundimartin.maku...@koodaripalvelut.com wrote:
DropDownChoice? extends BaseClass dropDown = new DropDownChoice?
extends BaseClass(id);
You can't instantiate with a wildcard type. That's not allowed by the
Java language.
Ah yes... I'm getting
OK, my own fault:
DropDownChoice? extends BaseClass ps = new
DropDownChoiceBaseClass() so the variable type spoils it.
**
Martin
2009/6/13 James Carman jcar...@carmanconsulting.com:
On Sat, Jun 13, 2009 at 9:25 AM, Martin
Makundimartin.maku...@koodaripalvelut.com wrote:
DropDownChoice?
I have casting problem:
dropDown = new DropDownChoice? extends BaseClass(, new
ChoiceRendererBaseClass(...));
dropDown.getChoiceRenderer().getDisplayValue(dropDown.getModelObject());
-- DOES NOT COMPILE
Is this a wicket bug or bug in me?
**
Martin
new DropDownChoiceBaseClass ?
-igor
On Fri, Jun 12, 2009 at 6:06 AM, Martin
Makundimartin.maku...@koodaripalvelut.com wrote:
I have casting problem:
dropDown = new DropDownChoice? extends BaseClass(, new
ChoiceRendererBaseClass(...));
new DropDownChoiceBaseClass ?
Maybe ...
**
Martin
On Fri, Jun 12, 2009 at 6:06 AM, Martin
Makundimartin.maku...@koodaripalvelut.com wrote:
I have casting problem:
dropDown = new DropDownChoice? extends BaseClass(, new
ChoiceRendererBaseClass(...));
Just because the constructor is declared that way (with the ?) doesn't mean
you have to declare your variables that way.
On Jun 12, 2009 4:43 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
new DropDownChoiceBaseClass ?
Maybe ...
**
Martin
On Fri, Jun 12, 2009 at 6:06 AM,
declaration is not the problem. from what i remember from generics (I might
be wrong), you're not allowed to instantiate generically. you have to tell
the compiler exactly what type you want. at runtime it has no idea about
generics.
On Sat, Jun 13, 2009 at 12:41 AM, James Carman
But, the compiler only knows what you're allowed to do by the type of
the variable. You do not need to declare your variables with the
wildcards.
On Fri, Jun 12, 2009 at 6:31 PM, Cristi Manolecristiman...@gmail.com wrote:
declaration is not the problem. from what i remember from generics (I
I may be the dumb kid on the block, but why do we need to override
setModel and getModel( ) once it has already been done in Component class? (
meaning just have it in component class and then let all subclasses use the
same methods?)
Am i missing something?
Rick
On Sat, Jun 7, 2008 at 2:49 PM,
If the subclass wants type safety (returning T rather than Object),
then they would override getModelObject(). This is allowed because of
Java's covariant return types feature. However, there's no such thing
as covariant parameter types, so overriding the setter won't work.
On Tue, Jun 10, 2008
Hi,
if the consequences are a cleaner api then I think to decouple the model is
right.
The migration for older code may be hard. But I think it will be worth it
when the new code base is more robust.
--
View this message in context:
http://www.nabble.com/wicket-generics-tp17706107p17757524
I don't know if i was clear enough, sorry about that.
I meant if you have something like :
public ComponentMODEL extends IMODELID, ID extends Serializable{
// getter here
public MODEL getModel() { }
// setter here
public void setModel(final MODEL model){ }
}
then, you don't have to do
which is exactly what we are trying to avoid - having generics in Component.
-Matej
On Tue, Jun 10, 2008 at 6:19 PM, Ricky [EMAIL PROTECTED] wrote:
I don't know if i was clear enough, sorry about that.
I meant if you have something like :
public ComponentMODEL extends IMODELID, ID extends
Hmmph, a weird fact to consider though is that when you are
Non-generifying the Component class, it doesn't make sense as to why one
would have XXComponent be generically typed to something, like a 'T' which
is also generic type for IModel, I mean the whole idea is to de-couple the
component
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void setmodel(imodel? model) {...}
public imodel? getmodel();
}
that is all good until you want to have
+1 for do it right, no matter if the api breaks or not
Am 07.06.2008 um 09:20 schrieb Igor Vaynberg:
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void
hi igor,
that's a mess. :-(
i would go for decoupling component/model for 1.4 - that makes a clean cut for
the api towards generics. everything else is just half-baked.
my 2c, --- jan.
-
To unsubscribe, e-mail: [EMAIL
On Sat, Jun 7, 2008 at 8:20 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
thoughts and ideas?
Is there much else apart from Generic's that's in 1.4 that would
benefit from a release 'sooner' rather than 'later'?
I know the intentions's not to have it much different, but not
changing 1.3's
type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void setmodel(imodel? model) {...}
public imodel? getmodel();
}
that is all good until you want to have a generified subclass eg a listitem:
class
and that generics only pointed out this problem.
Regards,
Sebastiaan
Igor Vaynberg wrote:
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void setmodel
Hi Igor and others,
Great that you tried that out in practice!
On Sat, 07 Jun 2008, Igor Vaynberg wrote:
class component {
public void setmodel(imodel? model) {...}
public imodel? getmodel();
}
I was earlier trying out this variant:
public class Component {
public T Component
i dont think listitem#setmodel is restricted in your example.to T in ListItemT
public T ListItem setModel(IModelT model)
the first T hides the T of ListItemT so you might as well have
said X setModel(IModelX model)
-igor
On Sat, Jun 7, 2008 at 4:48 AM, Timo Rantalaiho [EMAIL PROTECTED]
On Sat, 07 Jun 2008, Igor Vaynberg wrote:
i dont think listitem#setmodel is restricted in your example.to T in
ListItemT
public T ListItem setModel(IModelT model)
the first T hides the T of ListItemT so you might as well have
said X setModel(IModelX model)
Heh, you're right of
28 matches
Mail list logo
