On Mon, Jul 14, 2008 at 5:03 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
> I think you are *not* in the minority, but a lot of the dissenters piped in
> last minute in a big flood so to some it might look that way.
I think this is a baseless statement: both sides have been very vocal.
In any case this will not be a majority vote unless there is a 1-99%
split, but even then: the core committers have the final say and it is
their responsibility to move the project forward in the way they deem
to be in the best interest of the framework. This doesn't say the
wicket committers don't value your input, nor won't take it into
account (lots of double negatives). In other words: we *do* value your
input and feedback, and will take it into account, but the ultimate
responsibility lies with the core committers.
> However, It may actually be valuable the way they are doing it now, so I'm
> reserving judgement until I can sit down and port my latest project to it...
> and check out how well it works.
This is what we ask, so thanks and please provide feedback!
> The moment I have to do a cast, I'll consider it a sign that it needs more
> work.
This is what we propose: when you come across a point where generics
should be added, give us a note. We will take it into consideration,
just as we do with removing "final" in our code base.
Martijn
> On 14-Jul-08, at 10:17 AM, Craig McIlwee wrote:
>
>>
>> personally i am still in favor of going with the m2 way of doing things
>> where
>> Component is generic, but from the looks of the discussion i think i may
>> be
>> in the minority here. this kinda surprises me though because as i read
>> the
>> original generic discussion it sounded like most people supported
>> Component<T>.
>>
>>
>> igor.vaynberg wrote:
>>>
>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>>> is a call for confirmation/discussion from our user base.
>>>
>>
>> 1) i'm not sure i agree with this. i don't feel that just adding <Void>
>> to
>> components that don't need their models makes things messy. i'd much
>> rather
>> have the option to use generics whenever i need than to create extra
>> classes
>> such as the 'GenericPanel', etc that have been mentioned. in fact i think
>> its alot messier to create more classes and to start changing method names
>> (getDefaultModel, etc) and then adding getModel to the classes that do use
>> generics.
>>
>> 2) the wicket web site now suggests the following code for generic
>> components:
>>
>> @SuppressWarnings("unchecked")
>> public final T getModelObject()
>> {
>> return (T)getDefaultModelObject();
>> }
>>
>> ... but isn't the purpose of adding generic support to wicket to prevent
>> the
>> need for unchecked casts? if we now have to place unchecked casts into
>> our
>> code then we lose out on the strong type checking that generics are
>> supposed
>> to provide. its not hard to imagine a case where one part of someone's
>> code
>> calls setDefaultModelObject with the wrong type, and then later another
>> part
>> of the code calls getModelObject and hits a class cast exception.
>>
>> 3) the Component class has several methods that return 'this' to allow for
>> method chaining. the problem here is that the generic components don't
>> override these methods with covariant returns, so if i do something like
>> formComponent.setVersioned(false).moreMethodCalls().chainedTogether()
>> then
>> those chained methods can't use models because we've upcast our component
>> to
>> something that doesn't have generic support. i guess the solution would
>> be
>> to put these calls on separate lines, but it seems like a bit of a hassle
>> (i'm probably just being picky tho)
>>
>> - craig
>> --
>> View this message in context:
>> http://www.nabble.com/generics-tp18083910p18444866.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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]
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
