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: IModel<String> 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 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]
>
>
