this only works for subclasses.
and if you do class myclass extends otherclass 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]> wrote:
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) ((ParameterizedType) getClass()
.getGenericSuperclass()).getActualTypeArguments()[0]
Regards,
Bernard.
Martin Voigt a écrit :
if we co
if we could get something like
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 th
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 stati
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 f
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
i added my comments on how generics should be in a javalobby/dzone thread
about java 7:
http://java.dzone.com/articles/java-7-and-art-patience
couldnt help myself :)
I think java 7 could help wicket in 2 areas
generics:
class Foo
{
Foo(){}
Foo(Bar){}
}
better type inference Foo
Yeah I for one would defiantly hate for compound model to go away..:(
But I guess one could come along away with propertymodel and when we get
the proxybase model aproach in it could be okay.
[1] https://issues.apache.org/jira/browse/WICKET-1327
James Carman wrote:
Those are definitely sti
Those are definitely sticking points. I guess we'll just have to
evaluate what is better for the framework. These two features are
definitely convenient.
On Wed, Oct 29, 2008 at 11:59 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> its not just compound
> we have 2 special cases for this:
> ICo
just dont write those!
On Wed, Oct 29, 2008 at 5:18 PM, Igor Vaynberg <[EMAIL PROTECTED]>wrote:
> yes, the inherited will have to most likely go away - but that is
> there only for the CPM.
>
> the icomponentassignedmodel is already broken if a component has more
> then one model because you have
yes, the inherited will have to most likely go away - but that is
there only for the CPM.
the icomponentassignedmodel is already broken if a component has more
then one model because you have to manually call wrap() on those
anyways...lately ive been writing a lot of components that take more
then
its not just compound
we have 2 special cases for this:
IComponentAssignedModel and IComponentInheritedModel
which will be both pretty tricky to do if the users must make a field for
the model them selfs.
but we will see.
johan
On Tue, Oct 28, 2008 at 5:22 PM, Igor Vaynberg <[EMAIL PROTECTED]>
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
aga
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 do
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
On Wed, Oct 29, 2008 at 1:13 AM, Artur W. <[EMAIL PROTECTED]> wrote:
>
> Hi Igor,
>
>
> igor.vaynberg wrote:
>>
>> 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 clas
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. unt
Hi Igor,
igor.vaynberg wrote:
>
> 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.
>
It is nice to know that somebody thinks similar to me :)
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.
i do think imodel makes a ton of sense, but the types on components
are pretty bad.
in 1.5 i have an
2:40
An: users@wicket.apache.org
Betreff: RE: Migration to 1.4 - generic headache
Hi Stefan!
Stefan Lindner wrote:
Use a Void Link (Link) or create your own Link wrapper class
Class MyLink extends Link
I know I can create a wrapper but it is a ugly was to solve my problem :/
The
8. Oktober 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 (Link) or create your own Link wrapper class
>
> Class MyLink extends Link
>
I know I can create a wrapper but it
Hi Stefan!
Stefan Lindner wrote:
>
> Use a Void Link (Link) or create your own Link wrapper class
>
> Class MyLink extends Link
>
I know I can create a wrapper but it is a ugly was to solve my problem :/
The Void think is a good idea but it doesn't work everywhere. For example
this doe
Use a Void Link (Link) or create your own Link wrapper class
Class MyLink extends Link
Stefan
-Ursprüngliche Nachricht-
Von: Artur W. [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 28. Oktober 2008 12:23
An: users@wicket.apache.org
Betreff: Migration to 1.4 - generic headache
H
23 matches
Mail list logo