taken from SUN's generic tutorial:
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
end of page 8
snip :::
interface Collection
{
public boolean containsAll(Collection c);
public boolean addAll(Collection c);
}
We could have used generic methods here instead:
interface Collection
{
p
this one will do:
public > void foo(Class clazz);
however, the subtle differences between this and igors version are
really hard to get.
Am 15.05.2008 um 16:31 schrieb Igor Vaynberg:
this is the usecase we are talking about. i get a compile error,
which sucks.
public class Test
{
yes and those i already came across some in wicket
i changed to and suddenly in extentions and/or examples compile errors
all over the place...
then i quickly turn it off again... (for now)
johan
On Thu, May 15, 2008 at 4:31 PM, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
> this is the usecase we
this is the usecase we are talking about. i get a compile error, which sucks.
public class Test
{
public static void main(String[] args)
{
Foo foo = new FooImpl();
foo.foo(IntegerComponent.class); // ok
foo.foo(Component.class); // compile error
}
public st
Igor Vaynberg wrote:
well, apparently johan ran into a situation where component is too
restrictive...
As I understand it, Johan ran into a situation where Component causes
*warnings* for users who use raw types. Which I've been arguing all
along that they SHOULD get: they should use Componen
i think something similar happend to me with Model.valueOf(Map), so
i had to change it back to return Model instead of Model
Gerolf
On Wed, May 14, 2008 at 11:41 PM, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
> well, apparently johan ran into a situation where component is too
> restrictive...
>
well, apparently johan ran into a situation where component is too
restrictive...
-igor
On Wed, May 14, 2008 at 2:37 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> Igor Vaynberg wrote:
>>
>> since then the thread has evolved into whether or not we should use > extends Component> or >
>>
>>
yeah, generics are pretty damn viral
-igor
On Wed, May 14, 2008 at 2:28 PM, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
> On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
> <[EMAIL PROTECTED]> wrote:
>>> the whole generics thing turned out to be
>>> quiet a lot crappier then i thought it would.
>>
Igor Vaynberg wrote:
since then the thread has evolved into whether or not we should use or >
-igor
I don't understand how that changes any of my points. The first is
incorrect (from a generics point of view) since you're referencing an
unparameterized generic type.
So the second gives wa
wicket 1.6 = scala-based ? *lol*
Am 14.05.2008 um 23:28 schrieb Eelco Hillenius:
On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
the whole generics thing turned out to be
quiet a lot crappier then i thought it would.
:-)
Generics for models: great. Generics for
On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
>> the whole generics thing turned out to be
>> quiet a lot crappier then i thought it would.
>
> :-)
Generics for models: great. Generics for components: awful. Too bad
that stuff is contagious.
Eelco
--
since then the thread has evolved into whether or not we should use or >
-igor
On Wed, May 14, 2008 at 1:54 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> Igor Vaynberg wrote:
>
>> i do like generics. did i ever say otherwise? the problem here is that
>> if we scope something as Class then
> the whole generics thing turned out to be
> quiet a lot crappier then i thought it would.
:-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Igor Vaynberg wrote:
i do like generics. did i ever say otherwise? the problem here is that
if we scope something as Class then even though
you ARE using generics in your code you will still get a warning
because we did not scope the class as Class>.
on the other hand if we do scope it as Class
that's exactly what I am saying...
It always pisses me off to see developers checking in code
that delivers like 50-100 warnings and they don't care.
warnings are a good thing.
not so sure about generics (just kidding :-)
Am 14.05.2008 um 22:41 schrieb Igor Vaynberg:
well, maybe you get use
well, maybe you get used to warnings, i tend to do something about
them and clean up my code. i do not want to turn this warning off,
because as you said yourself it is a very useful warning, if i turn it
off i might as well not be using generics...
-igor
On Wed, May 14, 2008 at 1:38 PM, Peter E
On Wed, May 14, 2008 at 1:20 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> Igor Vaynberg wrote:
>>
>> then our users have to suppress warnings in their code, which is
>> unacceptable at least to me. the whole generics thing turned out to be
>> quiet a lot crappier then i thought it would.
>
>
In IDEA it is annoying when you enable inspection 'Raw use of
parametrized class' which is generally quite useful
it will complain on
protected boolean isPageAuthorized(final Class
pageClass)
so, no, you don't get a warning but a potentially useful inspection is
more or less useless
just try it, line 6 will giveyou the warning, so we have no choice but
to declare it as Class>
01: public static class Test implements IAuthorizationStrategy {
02:public boolean isActionAuthorized(Component< ? > component,
Action action)
03:{
04:throw new UnsupportedOpe
how do users get in this situation a warning?
if we as a framework say method(RawType type)
then why would that give a warning in the caller method?
We just say we accept raw type there
johan
On Wed, May 14, 2008 at 9:53 PM, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
> then our users have to sup
Igor Vaynberg wrote:
then our users have to suppress warnings in their code, which is
unacceptable at least to me. the whole generics thing turned out to be
quiet a lot crappier then i thought it would.
I actually like having the generics better than not having it. In both
cases sometimes it's
then our users have to suppress warnings in their code, which is
unacceptable at least to me. the whole generics thing turned out to be
quiet a lot crappier then i thought it would.
-igor
On Wed, May 14, 2008 at 12:48 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> yes then all the call to that
yes then all the call to that method must be of a generic type.
cant be raw
i dont know what are we going to do in wicket i think we should decide it
should we just where we dont care about generic delete/not use the and
then
supresswarning?
johan
On Wed, May 14, 2008 at 9:45 PM, Igor Vaynberg
so i just implemented IAuthorizationStrategy and on this line in my class:
public boolean isInstantiationAuthorized(Class< ? extends Component>
componentClass)
i get: Component is a raw type. References to generic type
Component should be parameterized
so that means we have to change our sig to
That would cost more memory then it would gain
Now it is just 1 int field.. And do know that model isnt a field any
more by itself on component. Ok it is still a reference but that is
shared by behaviours and metadata.
So if we set it in a model, we would have created the model object
with a
so why dont we store the integer in the model then? save an extra
memory slot, because if you make it Void then no one can set the
modelobject anyways.
-igor
On Wed, May 14, 2008 at 8:28 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> hmm i will make it
> because the LoopItem doesnt really have
> >> generics", I
> >> respectfully disagree. One major point of generics is to avoid code
> >> duplication of boilerplate code. It it weren't for the need to
> >> create
> >> constructors, there wouldn't be any duplicated code. I
hmm i will make it
because the LoopItem doesnt really have a model with an Integer in the
model..
it has an primitive int itself stored in it self.
johan
On Wed, May 14, 2008 at 4:52 PM, Stefan Simik <[EMAIL PROTECTED]>
wrote:
>
> Great, it work without warnings now ;)
>
> Joham, could you ple
Great, it work without warnings now ;)
Joham, could you please change the following class too ?
file: Loop.java
line:53
from: LoopItem extends WebMarkupContainer
to: LoopItem extends WebMarkupContainer
thx ;)
Stefan
Johan Compagner wrote:
>
> i already did the commit just ye
gt;> generics", I
>> respectfully disagree. One major point of generics is to avoid code
>> duplication of boilerplate code. It it weren't for the need to
>> create
>> constructors, there wouldn't be any duplicated code. I agree that
>> it i
te:
imho, that seems like that adds a lot of unnecessary code. One of the
nice things about Wicket is that it keeps the bloat to a minimum.
-Original Message-
From: Doug Donohoe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 14, 2008 8:21 AM
To: users@wicket.apache.org
Subject: Re: Using generics
readability and
maintainability.
-Doug
Hoover, William wrote:
>
> imho, that seems like that adds a lot of unnecessary code. One of the
> nice things about Wicket is that it keeps the bloat to a minimum.
>
> -----Original Message-----
> From: Doug Donohoe [mailto:[EMAIL PROTECTED]
I can save you the trouble of generating the patch. I don't want
FooBar where Foo iterates over all the types in Java and Bar iterates
over all the Components, Behaviors, Sessions, Requests, Providers in
Wicket. Totally unnecessary and completely negates the idea of
generics.
Martijn
On 5/14/08,
generics with some non-generic classes in Wicket
Somewhat related to this thread, when I moved to generics win Wicket
1.4, I created some utility classes such as:
public class VoidContainer extends WebMarkupContainer<Void> public
class VoidPanel extends Panel<Void> public class StringL
Somewhat related to this thread, when I moved to generics win Wicket 1.4, I
created some utility classes such as:
public class VoidContainer extends WebMarkupContainer
public class VoidPanel extends Panel
public class StringLabel extends Label
public class IntegerModel exten
The problem is that wicket needs an annotation
so that all the warnings about raw types are gone.
A component only has to be generic if you use the IModel constructor or call
getModel(), getModelObject() methods..
for the rest it is not really needed
johan
On Wed, May 14, 2008 at 9:28 AM, Seb
My post kind of missed the point, I shouldn't post when I'm already half
asleep. :-)
Obviously MarkupContainer satisfies the MarkupContainer in a
method argument, so it accepts the raw type. However, it generates a
warning because the method says it's generified, so you should be using
the ge
I dont think that user gets a warning if a param is of raw type. But
we have a warning there.
The problem is that for example MarkupContainer.add(Component) or
IVisitor.visit(Component) i dont care what component is put in
generified or not.
In add it really doesnt matter because we dont do anythin
if we have a signature that accepts a raw type, will that also cause a
warning in user's code?
also having those suppress annotations practically _everywhere_ will be annoying
-igor
On Tue, May 13, 2008 at 11:56 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> I dont care, because i cant do any
I dont care, because i cant do any thing with the ? The only thing it
enforces is that it must now be a generic class which is annoying. Not
to mention that in that area eclipse and javac accept different
things
So or we in wicket dont use any where and have supress warning
everywhere for tha
Johan Compagner wrote:
yes thats the reason
you are calling the method add with a generified component but that
container itself is not generified
i dont like this about generics expecially the onces like this:
add(MarkupContainer container)
then suddenly a none generified component cant be a
yeah i know just wanted to give an example
But Label == String is not the really the same thing as ListView == List..
Because for a Label getModelObject() doesnt have to be a String (it can be
anything)
but for ListView.getModelObject() does have to be a List..
This is also because our converter
have not thought it through. i was just pointing out another option.
in some sense a label shows a string like a listview shows a list.
that's all.
Johan Compagner wrote:
>
> cant i have a Label that has a Date as a object?
> That is resolved by the converter for display?
>
> johan
>
>
>
i already did the commit just yet..
i did make them all because i think people generally dont want to
generify them anyway (use the model object)
On Tue, May 13, 2008 at 9:48 PM, Stefan Simik <[EMAIL PROTECTED]>
wrote:
>
> please, and will be these classes later generified ?
> Or should I ma
please, and will be these classes later generified ?
Or should I make a RFE, or can I help anyway-for example attach a patch ?
I love your work and Wicket, so I do my best, to make it better ;)
Stefan Simik
Johan Compagner wrote:
>
> yes thats the reason
>
> you are calling the method a
yes thats the reason
you are calling the method add with a generified component but that
container itself is not generified
i dont like this about generics expecially the onces like this:
add(MarkupContainer container)
then suddenly a none generified component cant be added...
thats really stup
cant i have a Label that has a Date as a object?
That is resolved by the converter for display?
johan
On Tue, May 13, 2008 at 6:09 PM, Jonathan Locke <[EMAIL PROTECTED]>
wrote:
>
>
> well, unless this:
>
> public class Label extends WebComponent
>
> became:
>
> public class Label extends WebC
well, unless this:
public class Label extends WebComponent
became:
public class Label extends WebComponent
not saying this is the right thing to do as it might break a lot of code,
but it would be more precise.
Johan Compagner wrote:
>
> the only thing i can quickly come up with is thi
I have one idea,
the reason of the warnigs is, that parent of AjaxPagingNavigator is
PagingNavigator,
which has parent Panel ---> that is not parameterized.
The same problem is with LoopItem, which extends the
WebMarkupContainer ---> that is not parameterized.
? could this be the reason ?
Mhmm, it is meaningful ;) I will know in future, thx
One of the last occuring warning is, when working with
MarkupContainer#add(...) or #addOrReplace(...) method.
Example: I have a simple AjaxPagingNavigator, to which I add a simple
ListView
--
no String != T
and the super constructor wants to have T not String.
and i think you cant in that constructor ok T == String so String is valid..
i have no idea how to do that.
johan
On Tue, May 13, 2008 at 5:23 PM, Stefan Simik <[EMAIL PROTECTED]>
wrote:
>
> Uuf, great :) It works ! Thx.
>
Uuf, great :) It works ! Thx.
But, is not String something Serializable ?
I cannot understand where was the problem,
but I know, this is more about Java Generics, not about Wicket.
Johan Compagner wrote:
>
> the only thing i can quickly come up with is this
>
> public ExtendLabe
the only thing i can quickly come up with is this
public ExtendLabel(String id, T string)
{
super(id, new Model(string));
}
On Tue, May 13, 2008 at 4:55 PM, Stefan Simik <[EMAIL PROTECTED]>
wrote:
>
> Thx Maurice, your are right. I was using Wicket 1.4M1.
>
Thx Maurice, your are right. I was using Wicket 1.4M1.
I checked out latest from trunk, and it OK. ;)
So another problematic compiler warning.
For example simple - subtype of Label, which has model type of anything
Serializable.
public class ExtendedLabel extends
Lab
It is generified in trunk, but it might be possible that it was not
yet at the time of the 1.4-m1 release.
Maurice
On Tue, May 13, 2008 at 3:47 PM, Stefan Simik <[EMAIL PROTECTED]> wrote:
>
> Hi boys,
>
> I would like to ask something about wicket generics. I have a warning, that
> I don't kno
55 matches
Mail list logo
