On Wed, May 21, 2008 at 12:24 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> ok so we pretty much have some core people wanting to back out the
> generics support.
I hate to say it, and I kept myself on the background because I don't
want to be a pita, but I still feel the same as I did last year:
generic models are cool, generic components ugly. Unfortunately, a
large part of the ugliness is due to Java's lack of type inference,
which results in that you have to state the type twice as often as
really necessary.
What I hate most about how 1.4 currently looks is just the verbosity.
I like the advantages more static typing can give us (a major selling
point of Wicket after all), but at the same time I have to admit that
I rarely if ever run into casting or refactoring problems with 1.3.
Also, I found that using constructs like:
public class DomainObjectModel<T extends DomainObject> extends
LoadableDetachableModel
...
public SiteNodePanel(String id, DomainObjectModel<SiteNode> rootNodeModel) {
work well enough for me, so I don't really miss generics in Wicket to
start with. (in the example I force that SiteNodePanel instances are
always created with a model that produces SiteNode objects).
> 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.
I'd to thank you guys for the effort. It's really cool you put in that
hard work, even if the results aren't as good as you hoped.
> 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.
I would be all for just using generics where it really provides a huge
benefit and where opinions on it don't differ too much. A few hard
choices will have to be made and judging from the discussion so far,
I'm afraid at least a couple of people will end up being quite
unhappy.
> so lets start a vote with a parallel discussion thread just for this.
Good idea. Let's do discussion first (thread on dev?) and let's not
rush things. How about gathering consensus of the parts we currently
do like?
Cheers,
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
