Hi Martin,
There *is* a way to evaluate the type parameter at runtime. Something
like the following will give you the first type used:
(Class<T>) ((ParameterizedType) getClass()
.getGenericSuperclass()).getActualTypeArguments()[0]
Regards,
Bernard.
Martin Voigt a écrit :
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, i'd
be more than happy, but that will stay a dream for a long time ;)
Regards,
Martin
2008/10/30 Ricky <[EMAIL PROTECTED]>:
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 static typed; generic notation
will be less DRY violating and more clear.
But its the conceptual approach that i am not sure I am following (which is
why said may be I shouldn't be posting this :)). A component has to have an
associated model type with it. Generifying models is mandatory... but from
what i see; not generifying components would be a big mistake.
I cannot see any model less component. A component interacts with underlying
application data using model wrapper ... that was the beauty of wicket that
i had come to love the most and if now we are saying that it is valid in
some cases and in some it isn't is contradictory. If anything; for
consistency sake we should go with component level generification. But i
guess i am in the minority in that issue.
Generics is something that java developers have to get used to and it takes
some time ... but just because it takes some time; we should choose a middle
ground solution isn't exactly right; may be more practical (oh well ;) ).
On Thu, Oct 30, 2008 at 2:34 PM, Johan Compagner <[EMAIL PROTECTED]>wrote:
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 for
that.
johan
On Thu, Oct 30, 2008 at 6:25 PM, Edward <[EMAIL PROTECTED]>
wrote:
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. Might as well get rid of the model all together.
When I first started using Wicket I admit I was shocked there were no
generics and I was accessing the model object all the time and casting.
As I got better at using Wicket though I found better ways of doing
things and I believe I haven't done a cast even once in the past 6
months - and I have developed some fairly complicated apps in that time.
I think 1.3 is designed very well and I like it a lot.
Edward
Jan Kriesten wrote:
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
against generics on Components which are not FormComponents (or
ListViews)!
I'm using Wicket together with Scala and other than with Java, I can't
just drop
the generics attributes (and live with the warnings). And the <Void> is
really a
hell of a generic...
Generics on Models are what is needed and if your vision to decouple
models from
the component and use introspection/reflection to support them comes
true
I'd be
quite happy (and could use Scala's mixin-feature to have my model
functionality
on the components).
Best regards, --- Jan.
---------------------------------------------------------------------
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]
--
Regards
Vyas, Anirudh
|| ॐ ||
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
