if we could get something like
T default Void
from sun, all my generics problems would go away.
no code clutter anymore just because you generify classes that
should be. and type safety would still be ensured at runtime. if the
vm would give me a way to evaluate the type parameter at runtime,
Hi Martin,
There *is* a way to evaluate the type parameter at runtime. Something
like the following will give you the first type used:
(ClassT) ((ParameterizedType) getClass()
.getGenericSuperclass()).getActualTypeArguments()[0]
Regards,
Bernard.
Martin Voigt a écrit :
if we
this only works for subclasses.
and if you do class myclassa,b extends otherclassb you have to map
the entire class hierarchy to figure out how [0] maps to your expected
type. in the example above you actually want [1].
-igor
On Fri, Oct 31, 2008 at 7:23 AM, Bernard Niset [EMAIL PROTECTED]
that it will be
abandon in a year or something.
Thanks in advance,
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20205449.html
Sent from the Wicket - User mailing list archive at Nabble.com
Well I'll speak up and say I don't like generics in Wicket. I like them
in other places... just not here. It is a lot of extra ugly code just
to fix the rare occurrence that I have to cast the model object.
Not to mention in my opinion it breaks the data abstraction the model
provides.
i agree and we only need 2 things to be fixed improved by sun and then all
the current problems are completely gone
But i guess we never get them
Because they find JavaFX way more importand.. I am glad the focused on that
because it gave us Java6U10 but that whole JavaFX i dont have much hope
I don't know if i should speak up amongst elite group of people discussing,
but hey i'll try ... :)
From what i understand most people have issues with readability of generics;
but as i have indicated time and again as java improves and generic types
become reified; and java becomes inferred
:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20222475.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Hi Igor,
yes it sucks. i agree. personally i prefer code written against wicket
1.3. even in 1.3 i hardly had to cast anything and even with those
casts i do not remember getting any class cast exceptions.
hehe - just as I was saying months ago. *g*
anyways, we will see how it goes. until
because at least you
have your models generified and your component constructors expect the
right model types.
-igor
Thanks in advance for your advices.
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20222475.html
Sent from the Wicket
you are against generics completely. but they are going to happen. the
way they are now is not perfect, in 1.5 we will try to move them to a
better place, but like it or not they are here to stay.
-igor
On Wed, Oct 29, 2008 at 1:28 AM, Jan Kriesten
[EMAIL PROTECTED] wrote:
Hi Igor,
yes it
the fact remains that there are components that are sometimes used
with a model and sometimes without one. as it is we only generify
components that we *think* are most likely to be used with a model,
this is why we spent many an hour backing out generics from Component.
it is too bad that java
Hi Igor,
you are against generics completely. but they are going to happen. the
way they are now is not perfect, in 1.5 we will try to move them to a
better place, but like it or not they are here to stay.
huh - hell, no, I'm not against generics at all. Where do you get that from? I'm
that it will be
abandon in a year or something.
Thanks in advance,
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20205449.html
Sent from the Wicket - User mailing list archive at Nabble.com
is there any way to workaround about this warnings problem?
I don't want to stay with wicket 1.3 because I realize that it will be
abandon in a year or something.
Thanks in advance,
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache
that it will be
abandon in a year or something.
Thanks in advance,
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20205449.html
Sent from the Wicket - User mailing list archive at Nabble.com
in advance,
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20205449.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e
:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20205449.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
.
Thanks in advance,
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20205449.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail
this doesn't compile:
new AjaxButton(cancelButton) {
@Override
protected void onSubmit(AjaxRequestTarget target, Formlt;Voidgt;
form) {
modal.close(target);
}
}
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache
2008 12:40
An: users@wicket.apache.org
Betreff: RE: Migration to 1.4 - generic headache
Hi Stefan!
Stefan Lindner wrote:
Use a Void Link (LinkVoid) or create your own Link wrapper class
Class MyLink extends LinkVoid
I know I can create a wrapper but it is a ugly was to solve my
@wicket.apache.org
Betreff: RE: Migration to 1.4 - generic headache
Hi Stefan!
Stefan Lindner wrote:
Use a Void Link (LinkVoid) or create your own Link wrapper class
Class MyLink extends LinkVoid
I know I can create a wrapper but it is a ugly was to solve my problem :/
The Void think
in advance,
Artur
--
View this message in context:
http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20205449.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail
23 matches
Mail list logo
