+1
-----Original Message-----
From: Brill Pappin [mailto:
brill@...]
Sent: Monday, June 02, 2008 10:49 AM
To:
users@...
Subject: RE: users, please give us your opinion: what is your take on
generics with Wicket
I don't know, I think the discussion is going *toward* generics.
Frankly I can't even see why its an issue at all, the language has
evolved and uses them... Why would Wicket not also use them its inline
with the current state of the language?
There is no reason that people who can't get their heads around Generics
can't use the older releases that don't include it, but IMO any java
developer who doesn't get generics yet better make some time to learn,
because like it or not, they *will* be dealing with them.
- Brill Pappin
-----Original Message-----
From: Matej Knopp [mailto:
matej.knopp@...]
Sent: Monday, June 02, 2008 10:46 AM
To:
users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state. I think before
we even think of (partially) reverting generics we have to discuss
what's wrong (except the verbosity of course, but that's not something
we can really do
about) with current state. I use wicket with generics daily and I don't
see any particular show stopper so far.
Also If i had to decide between new WebMarkupContainer<Void> and new
WebMarkupContainer where the later wouldn't be generified I'd certainly
go for the <Void> alternative.
-Matej
On Sun, Jun 1, 2008 at 10:44 PM, Eelco Hillenius
<
eelco.hillenius@...>
wrote:
> Hi all,
>
> We have had several threads in this and the dev list, and some
> discussions in the public on how to incorporate generics in Wicket.
>
> I'd like to use this thread to gather the opinions of as many regular
> Wicket users as we can. Please help us get an impression of what our
> users think about the issue by completing this simple survey. Note
> that it is not a vote; we only want to get an idea of what you think.
>
> 1) Generifying* Wicket
> [ ] Can best be done like currently in the 1.4 branch, where models
> and components are both generified. I care most about the improved
> static type checking generified models and components give Wicket.
> [ ] Can best be done in a limited fashion, where we only generify
> IModel but not components. I care more about what generifying can do
> for API clarity (declaring a component to only accept certain models
> for instance) than static type checking.
> [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
> in your opinion here).
> [ ] .... (anything other than these choices?)
>
> 2) How strongly do you feel about your choice above?
> [ ] Whatever choice ultimately made, I'll happily convert/ start
> using 1.4 and up.
> [ ] I might rethink upgrading if my choice doesn't win.
> [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
> preference.
>
> Thanks in advance for everyone participating, and pls feel free to
> explain yourself further beyond just answering these questions!
>
> Eelco
>
> p.s. I suggest that the core devs and most active participants and
> previous discussions wait a few days before giving their opinions so
> that we don't flood the thread right from the start.
>
> * Parameterizing would probably be the better word to use, but
> generifying seems to be the word that many people use.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
users-unsubscribe@...
> For additional commands, e-mail:
users-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@...
For additional commands, e-mail:
users-help@...
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@...
For additional commands, e-mail:
users-help@...
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@...
For additional commands, e-mail:
users-help@...