Yeah, it could even be in its separate utility class:
interface IModel<T> {}
class Component {
private IModel<?> model;
public IModel<?> getModel() {
return model;
}
}
public class Unsafe {
public static <T> IModel<T> cast(IModel<?> model) {
return (IModel<T>) model;
}
}
class MyComp extends Component {
public MyComp() {
IModel<Integer> 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> IModel<T> getModel() {
> > return (IModel<T>) 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> IModel<V> 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 -1000000000000000^1000000000000 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]
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
