OK, my own fault:
DropDownChoice ps = new
DropDownChoice() so the variable type spoils it.
**
Martin
2009/6/13 James Carman :
> On Sat, Jun 13, 2009 at 9:25 AM, Martin
> Makundi wrote:
DropDownChoice dropDown = new DropDownChoice>>> extends BaseClass>("id");
>>>
>>> You can't instantiate wi
On Sat, Jun 13, 2009 at 9:25 AM, Martin
Makundi wrote:
>>> DropDownChoice 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
>> DropDownChoice 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 DropDownChoice("id") but the method
getChoiceR
On Sat, Jun 13, 2009 at 8:13 AM, Martin
Makundi wrote:
> Hi!
>
> Yes.. this is true but not ideally consistent. More consistent would be
>
> DropDownChoice dropDown = new DropDownChoice extends BaseClass>("id");
You can't instantiate with a wildcard type. That's not allowed by the
Java language.
Hi!
Yes.. this is true but not ideally consistent. More consistent would be
DropDownChoice dropDown = new DropDownChoice("id");
in such a way that dropDown.getChoiceRenderer() would be automatically
of type .
One solution would be to change the signature of DropDownChoice (and
selectchoices ...
No casting is required. Try this:
BaseClass baseObject = null;
DropDownChoice dropDown = new DropDownChoice("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 I said, you don't
No. The compiler does not allow. If DropDownChoice is of type then the problem is that it assumes that
getChoiceRenderer() is also of type . Now at
runtime, because of the wildcard, I do not know what class I have, and
I absolutely cannot use the renderer. The only workaround is to cast
the render
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 Manole wrote:
> declaration is not the problem. from what i remember from generics (I might
> be wrong), you're
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
wrote:
> Just
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 DropDownChoice ?
Maybe ...
**
Martin
> > On Fri, Jun 12, 2009 at 6:06 AM, Martin
> new DropDownChoice ?
Maybe ...
**
Martin
>
> On Fri, Jun 12, 2009 at 6:06 AM, Martin
> Makundi wrote:
>> I have casting problem:
>>
>> dropDown = new DropDownChoice(, new
>> ChoiceRenderer(...));
>>
>> dropDown.getChoiceRenderer().getDisplayValue(dropDown.getModelObject());
>> <-- DOES NOT
new DropDownChoice ?
-igor
On Fri, Jun 12, 2009 at 6:06 AM, Martin
Makundi wrote:
> I have casting problem:
>
> dropDown = new DropDownChoice(, new
> ChoiceRenderer(...));
>
> dropDown.getChoiceRenderer().getDisplayValue(dropDown.getModelObject());
> <-- DOES NOT COMPILE
>
> Is this a wicket
I have casting problem:
dropDown = new DropDownChoice(, new
ChoiceRenderer(...));
dropDown.getChoiceRenderer().getDisplayValue(dropDown.getModelObject());
<-- DOES NOT COMPILE
Is this a wicket bug or bug in me?
**
Martin
-
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 cla
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 Component, ID extends Serializable>{
>
I don't know if i was clear enough, sorry about that.
I meant if you have something like :
public Component, ID extends Serializable>{
// getter here
public MODEL getModel() { }
// setter here
public void setModel(final MODEL model){ }
}
then, you don't have to do anything, basically all yo
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
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
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
On Sat, 07 Jun 2008, Igor Vaynberg wrote:
> i dont think listitem#setmodel is restricted in your example.to T in
> ListItem
>
> >public ListItem setModel(IModel model)
>
> the first hides the T of ListItem so you might as well have
> said setModel(IModel model)
Heh, you're right of cours
i dont think listitem#setmodel is restricted in your example.to T in ListItem
>public ListItem setModel(IModel model)
the first hides the T of ListItem so you might as well have
said setModel(IModel model)
-igor
On Sat, Jun 7, 2008 at 4:48 AM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
>
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 Component setMo
the 1-1 model-component coupling
> 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 wh
he 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 a generified subclass eg a listit
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 overri
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 PRO
+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
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 a
28 matches
Mail list logo
