|
»
»
users, please give us your opinion: what is your take on generics with Wicket
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14 - 15 | Next > |
 |
Making Component easier to Generify
by cowwoc
::
Rate this Message:
Have you considered moving from subclassing to composition in Wicket using Callable<T>? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable<T> instead of T, so for example setVisible(boolean) would become setVisible(Callable<Boolean>) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable<T> for constant values, such as Callable.valueOf(true) would return a Callable<Boolean> that always returns true. |
|
|
Re: Making Component easier to Generify
by Matej Knopp
::
Rate this Message:
Apart from the fact that this would be even more verbose than current
generics approach this would probably also radically increase component memory footprint. -Matej On Thu, Jun 12, 2008 at 7:03 AM, cowwoc <cowwoc@...> wrote: > > > Have you considered moving from subclassing to composition in Wicket using > Callable<T>? > > Currently it is quite common for developers to subclass a component in order > to override isVisible() and other properties. I am proposing that instead > the component classes become final and properties may only be set using > setter methods. The setter methods would take Callable<T> instead of T, so > for example setVisible(boolean) would become setVisible(Callable<Boolean>) > > The benefit of this approach is that you could introduce static factory > methods to the Wicket components which would make them much easier to use in > their Generic form. You could then introduce various helper classes to > create Callable<T> for constant values, such as Callable.valueOf(true) would > return a Callable<Boolean> that always returns true. > -- > View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by cowwoc
::
Rate this Message:
You could reduce the verbosity by combining all your dynamic content (anything you would normally add when subclassing a component) into a separate class. For example: class Images { Callable<Boolean> isVisible() { ... } Callable<Integer> getItemsPerPage() { ... } } main() { DataView<Image> images = DataView.create(); // factory method Images imageState = new Images(); images.setItemsPerPage(imageState.getItemsPerPage()); images.setVisible(imageState.isVisible()); ... } Gili
|
|
|
Re: Making Component easier to Generify
by Brill Pappin
::
Rate this Message:
on removing the finals
The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: > > > Have you considered moving from subclassing to composition in Wicket > using > Callable<T>? > > Currently it is quite common for developers to subclass a component > in order > to override isVisible() and other properties. I am proposing that > instead > the component classes become final and properties may only be set > using > setter methods. The setter methods would take Callable<T> instead of > T, so > for example setVisible(boolean) would become > setVisible(Callable<Boolean>) > > The benefit of this approach is that you could introduce static > factory > methods to the Wicket components which would make them much easier > to use in > their Generic form. You could then introduce various helper classes to > create Callable<T> for constant values, such as > Callable.valueOf(true) would > return a Callable<Boolean> that always returns true. > -- > View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by cowwoc
::
Rate this Message:
Brill,
This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili
|
|
|
Re: Making Component easier to Generify
by Brill Pappin
::
Rate this Message:
I understand the reasoning, however I think "best practice" can be
debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: > > Brill, > > This is actually an API "best practice". Classes fall into two > categories: > ones designed for subclassing, and ones designed to be final. The > same goes > for methods. Swing is full of examples of what goes wrong when people > override methods in classes that haven't been designed with > subclassing in > mind. > > Gili > > > Brill Pappin wrote: >> >> on removing the finals >> >> The final members are the worst thing I've had to deal with in Wicket >> so far. >> Although I understand that there may be a reason for them, they are >> more a hinderance than anything else and seem to be trying to >> "protect >> users from themselves". >> >> - Brill Pappin >> >> >> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >> >>> >>> >>> Have you considered moving from subclassing to composition in Wicket >>> using >>> Callable<T>? >>> >>> Currently it is quite common for developers to subclass a component >>> in order >>> to override isVisible() and other properties. I am proposing that >>> instead >>> the component classes become final and properties may only be set >>> using >>> setter methods. The setter methods would take Callable<T> instead of >>> T, so >>> for example setVisible(boolean) would become >>> setVisible(Callable<Boolean>) >>> >>> The benefit of this approach is that you could introduce static >>> factory >>> methods to the Wicket components which would make them much easier >>> to use in >>> their Generic form. You could then introduce various helper >>> classes to >>> create Callable<T> for constant values, such as >>> Callable.valueOf(true) would >>> return a Callable<Boolean> that always returns true. >>> -- >>> View this message in context: >>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > -- > View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by jwcarman
::
Rate this Message:
On Thu, Jun 12, 2008 at 11:08 AM, Brill Pappin <brill@...> wrote:
> I understand the reasoning, however I think "best practice" can be debated. > To use your example Swing allows the user to override quite a bit, and it > doesn't make any (or very few) assumptions on what should and should not be > done. > > I don't like API's that assume I'm an idiot and prevent me from manipulating > them how I see fit. If I cause a bug that I have to deal with, thats *my* > problem to resolve. > > In my book (and I'm not the only one) excessive use of final is an > anti-pattern. While I agree that using final all over the place is in general a bad idea, there are other reasons to use the final modifier on a method. It can also help performance (although these particular cases might not be good examples of where you'd want to squeeze every last bit of performance out at the cost of disallowing extensibility). --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by Martijn Dashorst
::
Rate this Message:
Without the use of final wicket would not have made it this far.
Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <brill@...> wrote: > I understand the reasoning, however I think "best practice" can be debated. > To use your example Swing allows the user to override quite a bit, and it > doesn't make any (or very few) assumptions on what should and should not be > done. > > I don't like API's that assume I'm an idiot and prevent me from manipulating > them how I see fit. If I cause a bug that I have to deal with, thats *my* > problem to resolve. > > In my book (and I'm not the only one) excessive use of final is an > anti-pattern. > > - Brill Pappin > > On 12-Jun-08, at 10:01 AM, cowwoc wrote: > >> >> Brill, >> >> This is actually an API "best practice". Classes fall into two categories: >> ones designed for subclassing, and ones designed to be final. The same >> goes >> for methods. Swing is full of examples of what goes wrong when people >> override methods in classes that haven't been designed with subclassing in >> mind. >> >> Gili >> >> >> Brill Pappin wrote: >>> >>> on removing the finals >>> >>> The final members are the worst thing I've had to deal with in Wicket >>> so far. >>> Although I understand that there may be a reason for them, they are >>> more a hinderance than anything else and seem to be trying to "protect >>> users from themselves". >>> >>> - Brill Pappin >>> >>> >>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>> >>>> >>>> >>>> Have you considered moving from subclassing to composition in Wicket >>>> using >>>> Callable<T>? >>>> >>>> Currently it is quite common for developers to subclass a component >>>> in order >>>> to override isVisible() and other properties. I am proposing that >>>> instead >>>> the component classes become final and properties may only be set >>>> using >>>> setter methods. The setter methods would take Callable<T> instead of >>>> T, so >>>> for example setVisible(boolean) would become >>>> setVisible(Callable<Boolean>) >>>> >>>> The benefit of this approach is that you could introduce static >>>> factory >>>> methods to the Wicket components which would make them much easier >>>> to use in >>>> their Generic form. You could then introduce various helper classes to >>>> create Callable<T> for constant values, such as >>>> Callable.valueOf(true) would >>>> return a Callable<Boolean> that always returns true. >>>> -- >>>> View this message in context: >>>> >>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by igor.vaynberg
::
Rate this Message:
indeed. i wouldnt mind if final was the default in java :)
-igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <martijn.dashorst@...> wrote: > Without the use of final wicket would not have made it this far. > > Martijn > > On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <brill@...> wrote: >> I understand the reasoning, however I think "best practice" can be debated. >> To use your example Swing allows the user to override quite a bit, and it >> doesn't make any (or very few) assumptions on what should and should not be >> done. >> >> I don't like API's that assume I'm an idiot and prevent me from manipulating >> them how I see fit. If I cause a bug that I have to deal with, thats *my* >> problem to resolve. >> >> In my book (and I'm not the only one) excessive use of final is an >> anti-pattern. >> >> - Brill Pappin >> >> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >> >>> >>> Brill, >>> >>> This is actually an API "best practice". Classes fall into two categories: >>> ones designed for subclassing, and ones designed to be final. The same >>> goes >>> for methods. Swing is full of examples of what goes wrong when people >>> override methods in classes that haven't been designed with subclassing in >>> mind. >>> >>> Gili >>> >>> >>> Brill Pappin wrote: >>>> >>>> on removing the finals >>>> >>>> The final members are the worst thing I've had to deal with in Wicket >>>> so far. >>>> Although I understand that there may be a reason for them, they are >>>> more a hinderance than anything else and seem to be trying to "protect >>>> users from themselves". >>>> >>>> - Brill Pappin >>>> >>>> >>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>>> >>>>> >>>>> >>>>> Have you considered moving from subclassing to composition in Wicket >>>>> using >>>>> Callable<T>? >>>>> >>>>> Currently it is quite common for developers to subclass a component >>>>> in order >>>>> to override isVisible() and other properties. I am proposing that >>>>> instead >>>>> the component classes become final and properties may only be set >>>>> using >>>>> setter methods. The setter methods would take Callable<T> instead of >>>>> T, so >>>>> for example setVisible(boolean) would become >>>>> setVisible(Callable<Boolean>) >>>>> >>>>> The benefit of this approach is that you could introduce static >>>>> factory >>>>> methods to the Wicket components which would make them much easier >>>>> to use in >>>>> their Generic form. You could then introduce various helper classes to >>>>> create Callable<T> for constant values, such as >>>>> Callable.valueOf(true) would >>>>> return a Callable<Boolean> that always returns true. >>>>> -- >>>>> View this message in context: >>>>> >>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.3 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by jwcarman
::
Rate this Message:
You mean like C++?
On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> wrote: > indeed. i wouldnt mind if final was the default in java :) > > -igor > > On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst > <martijn.dashorst@...> wrote: >> Without the use of final wicket would not have made it this far. >> >> Martijn >> >> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <brill@...> wrote: >>> I understand the reasoning, however I think "best practice" can be debated. >>> To use your example Swing allows the user to override quite a bit, and it >>> doesn't make any (or very few) assumptions on what should and should not be >>> done. >>> >>> I don't like API's that assume I'm an idiot and prevent me from manipulating >>> them how I see fit. If I cause a bug that I have to deal with, thats *my* >>> problem to resolve. >>> >>> In my book (and I'm not the only one) excessive use of final is an >>> anti-pattern. >>> >>> - Brill Pappin >>> >>> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >>> >>>> >>>> Brill, >>>> >>>> This is actually an API "best practice". Classes fall into two categories: >>>> ones designed for subclassing, and ones designed to be final. The same >>>> goes >>>> for methods. Swing is full of examples of what goes wrong when people >>>> override methods in classes that haven't been designed with subclassing in >>>> mind. >>>> >>>> Gili >>>> >>>> >>>> Brill Pappin wrote: >>>>> >>>>> on removing the finals >>>>> >>>>> The final members are the worst thing I've had to deal with in Wicket >>>>> so far. >>>>> Although I understand that there may be a reason for them, they are >>>>> more a hinderance than anything else and seem to be trying to "protect >>>>> users from themselves". >>>>> >>>>> - Brill Pappin >>>>> >>>>> >>>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>>>> >>>>>> >>>>>> >>>>>> Have you considered moving from subclassing to composition in Wicket >>>>>> using >>>>>> Callable<T>? >>>>>> >>>>>> Currently it is quite common for developers to subclass a component >>>>>> in order >>>>>> to override isVisible() and other properties. I am proposing that >>>>>> instead >>>>>> the component classes become final and properties may only be set >>>>>> using >>>>>> setter methods. The setter methods would take Callable<T> instead of >>>>>> T, so >>>>>> for example setVisible(boolean) would become >>>>>> setVisible(Callable<Boolean>) >>>>>> >>>>>> The benefit of this approach is that you could introduce static >>>>>> factory >>>>>> methods to the Wicket components which would make them much easier >>>>>> to use in >>>>>> their Generic form. You could then introduce various helper classes to >>>>>> create Callable<T> for constant values, such as >>>>>> Callable.valueOf(true) would >>>>>> return a Callable<Boolean> that always returns true. >>>>>> -- >>>>>> View this message in context: >>>>>> >>>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.3 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by igor.vaynberg
::
Rate this Message:
i mean generally, for methods, fields, and func args :) most of this
stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <james@...> wrote: > You mean like C++? > > On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> wrote: >> indeed. i wouldnt mind if final was the default in java :) >> >> -igor >> >> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >> <martijn.dashorst@...> wrote: >>> Without the use of final wicket would not have made it this far. >>> >>> Martijn >>> >>> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <brill@...> wrote: >>>> I understand the reasoning, however I think "best practice" can be debated. >>>> To use your example Swing allows the user to override quite a bit, and it >>>> doesn't make any (or very few) assumptions on what should and should not be >>>> done. >>>> >>>> I don't like API's that assume I'm an idiot and prevent me from manipulating >>>> them how I see fit. If I cause a bug that I have to deal with, thats *my* >>>> problem to resolve. >>>> >>>> In my book (and I'm not the only one) excessive use of final is an >>>> anti-pattern. >>>> >>>> - Brill Pappin >>>> >>>> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >>>> >>>>> >>>>> Brill, >>>>> >>>>> This is actually an API "best practice". Classes fall into two categories: >>>>> ones designed for subclassing, and ones designed to be final. The same >>>>> goes >>>>> for methods. Swing is full of examples of what goes wrong when people >>>>> override methods in classes that haven't been designed with subclassing in >>>>> mind. >>>>> >>>>> Gili >>>>> >>>>> >>>>> Brill Pappin wrote: >>>>>> >>>>>> on removing the finals >>>>>> >>>>>> The final members are the worst thing I've had to deal with in Wicket >>>>>> so far. >>>>>> Although I understand that there may be a reason for them, they are >>>>>> more a hinderance than anything else and seem to be trying to "protect >>>>>> users from themselves". >>>>>> >>>>>> - Brill Pappin >>>>>> >>>>>> >>>>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Have you considered moving from subclassing to composition in Wicket >>>>>>> using >>>>>>> Callable<T>? >>>>>>> >>>>>>> Currently it is quite common for developers to subclass a component >>>>>>> in order >>>>>>> to override isVisible() and other properties. I am proposing that >>>>>>> instead >>>>>>> the component classes become final and properties may only be set >>>>>>> using >>>>>>> setter methods. The setter methods would take Callable<T> instead of >>>>>>> T, so >>>>>>> for example setVisible(boolean) would become >>>>>>> setVisible(Callable<Boolean>) >>>>>>> >>>>>>> The benefit of this approach is that you could introduce static >>>>>>> factory >>>>>>> methods to the Wicket components which would make them much easier >>>>>>> to use in >>>>>>> their Generic form. You could then introduce various helper classes to >>>>>>> create Callable<T> for constant values, such as >>>>>>> Callable.valueOf(true) would >>>>>>> return a Callable<Boolean> that always returns true. >>>>>>> -- >>>>>>> View this message in context: >>>>>>> >>>>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>> >>> >>> >>> -- >>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>> Apache Wicket 1.3.3 is released >>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by jwcarman
::
Rate this Message:
That's funny. By default I make every local variable final if I can.
I guess it's just out of habit. I usually do the same for method parameters, too (I'm less diligent about that one). For methods, I usually just leave them be until I know for sure that I need them to be final. On Thu, Jun 12, 2008 at 11:42 AM, Igor Vaynberg <igor.vaynberg@...> wrote: > i mean generally, for methods, fields, and func args :) most of this > stuff can stay final, but people dont bother doing it because its > extra typing. > > -igor > > On Thu, Jun 12, 2008 at 8:38 AM, James Carman > <james@...> wrote: >> You mean like C++? >> >> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> wrote: >>> indeed. i wouldnt mind if final was the default in java :) >>> >>> -igor >>> >>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>> <martijn.dashorst@...> wrote: >>>> Without the use of final wicket would not have made it this far. >>>> >>>> Martijn >>>> >>>> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <brill@...> wrote: >>>>> I understand the reasoning, however I think "best practice" can be debated. >>>>> To use your example Swing allows the user to override quite a bit, and it >>>>> doesn't make any (or very few) assumptions on what should and should not be >>>>> done. >>>>> >>>>> I don't like API's that assume I'm an idiot and prevent me from manipulating >>>>> them how I see fit. If I cause a bug that I have to deal with, thats *my* >>>>> problem to resolve. >>>>> >>>>> In my book (and I'm not the only one) excessive use of final is an >>>>> anti-pattern. >>>>> >>>>> - Brill Pappin >>>>> >>>>> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >>>>> >>>>>> >>>>>> Brill, >>>>>> >>>>>> This is actually an API "best practice". Classes fall into two categories: >>>>>> ones designed for subclassing, and ones designed to be final. The same >>>>>> goes >>>>>> for methods. Swing is full of examples of what goes wrong when people >>>>>> override methods in classes that haven't been designed with subclassing in >>>>>> mind. >>>>>> >>>>>> Gili >>>>>> >>>>>> >>>>>> Brill Pappin wrote: >>>>>>> >>>>>>> on removing the finals >>>>>>> >>>>>>> The final members are the worst thing I've had to deal with in Wicket >>>>>>> so far. >>>>>>> Although I understand that there may be a reason for them, they are >>>>>>> more a hinderance than anything else and seem to be trying to "protect >>>>>>> users from themselves". >>>>>>> >>>>>>> - Brill Pappin >>>>>>> >>>>>>> >>>>>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Have you considered moving from subclassing to composition in Wicket >>>>>>>> using >>>>>>>> Callable<T>? >>>>>>>> >>>>>>>> Currently it is quite common for developers to subclass a component >>>>>>>> in order >>>>>>>> to override isVisible() and other properties. I am proposing that >>>>>>>> instead >>>>>>>> the component classes become final and properties may only be set >>>>>>>> using >>>>>>>> setter methods. The setter methods would take Callable<T> instead of >>>>>>>> T, so >>>>>>>> for example setVisible(boolean) would become >>>>>>>> setVisible(Callable<Boolean>) >>>>>>>> >>>>>>>> The benefit of this approach is that you could introduce static >>>>>>>> factory >>>>>>>> methods to the Wicket components which would make them much easier >>>>>>>> to use in >>>>>>>> their Generic form. You could then introduce various helper classes to >>>>>>>> create Callable<T> for constant values, such as >>>>>>>> Callable.valueOf(true) would >>>>>>>> return a Callable<Boolean> that always returns true. >>>>>>>> -- >>>>>>>> View this message in context: >>>>>>>> >>>>>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >>>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>>> Apache Wicket 1.3.3 is released >>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
RE: Making Component easier to Generify
by lzappaterrini
::
Rate this Message:
It is not about assuming anyone is an idiot. It is about preserving
maintainability and allowing an API to evolve without breaking client code. The best approach is to mark members as final unless there is a compelling reason not to. Final is a safeguard for APIs to know what behavior is guaranteed to persist as development and evolution of the API is carried out. Occasionally a user can come up with a good argument for removing the final restriction and makes their case, affecting a change. It is very easy to create an evolutionary dead end for an API by allowing everything to be overridden. So either deprecate and start over or risk breaking client code and have your users hate you for it :) -----Original Message----- From: Brill Pappin [mailto:brill@...] Sent: Thursday, June 12, 2008 11:09 AM To: users@... Subject: Re: Making Component easier to Generify I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: > > Brill, > > This is actually an API "best practice". Classes fall into two > categories: > ones designed for subclassing, and ones designed to be final. The > same goes > for methods. Swing is full of examples of what goes wrong when people > override methods in classes that haven't been designed with > subclassing in > mind. > > Gili > > > Brill Pappin wrote: >> >> on removing the finals >> >> The final members are the worst thing I've had to deal with in Wicket >> so far. >> Although I understand that there may be a reason for them, they are >> more a hinderance than anything else and seem to be trying to >> "protect >> users from themselves". >> >> - Brill Pappin >> >> >> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >> >>> >>> >>> Have you considered moving from subclassing to composition in Wicket >>> using >>> Callable<T>? >>> >>> Currently it is quite common for developers to subclass a component >>> in order >>> to override isVisible() and other properties. I am proposing that >>> instead >>> the component classes become final and properties may only be set >>> using >>> setter methods. The setter methods would take Callable<T> instead of >>> T, so >>> for example setVisible(boolean) would become >>> setVisible(Callable<Boolean>) >>> >>> The benefit of this approach is that you could introduce static >>> factory >>> methods to the Wicket components which would make them much easier >>> to use in >>> their Generic form. You could then introduce various helper >>> classes to >>> create Callable<T> for constant values, such as >>> Callable.valueOf(true) would >>> return a Callable<Boolean> that always returns true. >>> -- >>> View this message in context: >>> ur-take-on-generics-with-Wicket-tp17589984p17792488.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > -- > View this message in context: ur-take-on-generics-with-Wicket-tp17589984p17800710.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... ______________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by cowwoc
::
Rate this Message:
Actually, it's the other way around. Authors make methods final not because *you* might make a mistake but rather because *they* might. Using final methods simplifies their design a lot because they don't have to do all the work you mentioned. Secondly, it leaves the API open to extension (without breaking backwards compatibility) in a way that would be lost if anyone could override the methods. I personally agree with your approach with the following major caveat: if developers are able to override any method then it must be understood that any implementation making assumptions not guaranteed by the API specification is liable to break in future releases. Keep in mind that very few things ever are guaranteed by the specification, so practically speaking this means that your code is very likely to break as new releases come out. To be honest, I personally prefer approach #2 over final methods for public projects because (in my experience) even open-source projects take forever to fix bugs or add features that you might need right away. I'm a strong believer that implementations that make incorrect assumptions deserve to break in subsequent releases. One final benefit of #1 worth mentioning, however, is that incorrect assumptions end up in a compile-time error (roughly speaking) and even smart developers make mistakes every once in a while. Consider what happens if you override foo() and forget to invoke super.foo() by mistake. Those kinds of mistakes happen all the time. I'm toying with the idea that approach #1 makes sense for in-house projects where you are a co-owner and can make changes very quickly while approach #2 makes sense for public projects when developers can't afford to wait on the project owner. Put another way, maybe #1 makes sense for mature APIs whereas #2 makes sense for experimental APIs (used to flesh out the various use-cases you need to support). Gili
|
|
|
Re: Making Component easier to Generify
by Brill Pappin
::
Rate this Message:
That is the most compelling argument I have ever heard
(maintainability going forward). saying "i like this by default" as most have done is no argument at all :) However I disagree "best" is final by default... it should be the other way around, where things are only marked final if there is a good and immediate reason to do so. Although the debate is long and about as convoluted as the debate of hungarian notation was, personal experience suggests that everything final causes more problems than it's worth (I consider the Quartz API to be poor for that reason also). However, I am *in no way asking* the developers to reverse the "final" policy. its working, and working fairly well. I think I may have started a thread here that is less than productive and unless others feel that there needs to be a debate on the issue, I'll let it drop. - Brill Pappin On 12-Jun-08, at 11:50 AM, Zappaterrini, Larry wrote: > It is not about assuming anyone is an idiot. It is about preserving > maintainability and allowing an API to evolve without breaking client > code. The best approach is to mark members as final unless there is a > compelling reason not to. Final is a safeguard for APIs to know what > behavior is guaranteed to persist as development and evolution of the > API is carried out. Occasionally a user can come up with a good > argument > for removing the final restriction and makes their case, affecting a > change. > > It is very easy to create an evolutionary dead end for an API by > allowing everything to be overridden. So either deprecate and start > over > or risk breaking client code and have your users hate you for it :) > > -----Original Message----- > From: Brill Pappin [mailto:brill@...] > Sent: Thursday, June 12, 2008 11:09 AM > To: users@... > Subject: Re: Making Component easier to Generify > > I understand the reasoning, however I think "best practice" can be > debated. > To use your example Swing allows the user to override quite a bit, and > it doesn't make any (or very few) assumptions on what should and > should not be done. > > I don't like API's that assume I'm an idiot and prevent me from > manipulating them how I see fit. If I cause a bug that I have to deal > with, thats *my* problem to resolve. > > In my book (and I'm not the only one) excessive use of final is an > anti-pattern. > > - Brill Pappin > > On 12-Jun-08, at 10:01 AM, cowwoc wrote: > >> >> Brill, >> >> This is actually an API "best practice". Classes fall into two >> categories: >> ones designed for subclassing, and ones designed to be final. The >> same goes >> for methods. Swing is full of examples of what goes wrong when people >> override methods in classes that haven't been designed with >> subclassing in >> mind. >> >> Gili >> >> >> Brill Pappin wrote: >>> >>> on removing the finals >>> >>> The final members are the worst thing I've had to deal with in >>> Wicket >>> so far. >>> Although I understand that there may be a reason for them, they are >>> more a hinderance than anything else and seem to be trying to >>> "protect >>> users from themselves". >>> >>> - Brill Pappin >>> >>> >>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>> >>>> >>>> >>>> Have you considered moving from subclassing to composition in >>>> Wicket >>>> using >>>> Callable<T>? >>>> >>>> Currently it is quite common for developers to subclass a component >>>> in order >>>> to override isVisible() and other properties. I am proposing that >>>> instead >>>> the component classes become final and properties may only be set >>>> using >>>> setter methods. The setter methods would take Callable<T> instead >>>> of >>>> T, so >>>> for example setVisible(boolean) would become >>>> setVisible(Callable<Boolean>) >>>> >>>> The benefit of this approach is that you could introduce static >>>> factory >>>> methods to the Wicket components which would make them much easier >>>> to use in >>>> their Generic form. You could then introduce various helper >>>> classes to >>>> create Callable<T> for constant values, such as >>>> Callable.valueOf(true) would >>>> return a Callable<Boolean> that always returns true. >>>> -- >>>> View this message in context: >>>> > http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo > ur-take-on-generics-with-Wicket-tp17589984p17792488.html >>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>> >>>> >>>> > --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> -- >> View this message in context: > http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo > ur-take-on-generics-with-Wicket-tp17589984p17800710.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > ______________ > > The information contained in this message is proprietary and/or > confidential. If you are not the > intended recipient, please: (i) delete the message and all copies; > (ii) do not disclose, > distribute or use the message in any manner; and (iii) notify the > sender immediately. In addition, > please be aware that any message addressed to our domain is subject > to archiving and review by > persons other than the intended recipient. Thank you. > _____________ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by Brill Pappin
::
Rate this Message:
Very thoughtful and some good points, I don't entirely disagree with
that. - Brill On 12-Jun-08, at 11:54 AM, cowwoc wrote: > [...] --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by jwcarman
::
Rate this Message:
If you override a method and your implementation violates the Liskov
Substitution Principle, then it's your fault! :) On Thu, Jun 12, 2008 at 11:54 AM, cowwoc <cowwoc@...> wrote: > > > Actually, it's the other way around. Authors make methods final not because > *you* might make a mistake but rather because *they* might. Using final > methods simplifies their design a lot because they don't have to do all the > work you mentioned. Secondly, it leaves the API open to extension (without > breaking backwards compatibility) in a way that would be lost if anyone > could override the methods. > > I personally agree with your approach with the following major caveat: if > developers are able to override any method then it must be understood that > any implementation making assumptions not guaranteed by the API > specification is liable to break in future releases. Keep in mind that very > few things ever are guaranteed by the specification, so practically speaking > this means that your code is very likely to break as new releases come out. > > To be honest, I personally prefer approach #2 over final methods for public > projects because (in my experience) even open-source projects take forever > to fix bugs or add features that you might need right away. I'm a strong > believer that implementations that make incorrect assumptions deserve to > break in subsequent releases. One final benefit of #1 worth mentioning, > however, is that incorrect assumptions end up in a compile-time error > (roughly speaking) and even smart developers make mistakes every once in a > while. Consider what happens if you override foo() and forget to invoke > super.foo() by mistake. Those kinds of mistakes happen all the time. I'm > toying with the idea that approach #1 makes sense for in-house projects > where you are a co-owner and can make changes very quickly while approach #2 > makes sense for public projects when developers can't afford to wait on the > project owner. Put another way, maybe #1 makes sense for mature APIs whereas > #2 makes sense for experimental APIs (used to flesh out the various > use-cases you need to support). > > Gili > > > Brill Pappin wrote: >> >> I understand the reasoning, however I think "best practice" can be >> debated. >> To use your example Swing allows the user to override quite a bit, and >> it doesn't make any (or very few) assumptions on what should and >> should not be done. >> >> I don't like API's that assume I'm an idiot and prevent me from >> manipulating them how I see fit. If I cause a bug that I have to deal >> with, thats *my* problem to resolve. >> >> In my book (and I'm not the only one) excessive use of final is an >> anti-pattern. >> >> - Brill Pappin >> >> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >> >>> >>> Brill, >>> >>> This is actually an API "best practice". Classes fall into two >>> categories: >>> ones designed for subclassing, and ones designed to be final. The >>> same goes >>> for methods. Swing is full of examples of what goes wrong when people >>> override methods in classes that haven't been designed with >>> subclassing in >>> mind. >>> >>> Gili >>> >>> >>> Brill Pappin wrote: >>>> >>>> on removing the finals >>>> >>>> The final members are the worst thing I've had to deal with in Wicket >>>> so far. >>>> Although I understand that there may be a reason for them, they are >>>> more a hinderance than anything else and seem to be trying to >>>> "protect >>>> users from themselves". >>>> >>>> - Brill Pappin >>>> >>>> >>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>>> >>>>> >>>>> >>>>> Have you considered moving from subclassing to composition in Wicket >>>>> using >>>>> Callable<T>? >>>>> >>>>> Currently it is quite common for developers to subclass a component >>>>> in order >>>>> to override isVisible() and other properties. I am proposing that >>>>> instead >>>>> the component classes become final and properties may only be set >>>>> using >>>>> setter methods. The setter methods would take Callable<T> instead of >>>>> T, so >>>>> for example setVisible(boolean) would become >>>>> setVisible(Callable<Boolean>) >>>>> >>>>> The benefit of this approach is that you could introduce static >>>>> factory >>>>> methods to the Wicket components which would make them much easier >>>>> to use in >>>>> their Generic form. You could then introduce various helper >>>>> classes to >>>>> create Callable<T> for constant values, such as >>>>> Callable.valueOf(true) would >>>>> return a Callable<Boolean> that always returns true. >>>>> -- >>>>> View this message in context: >>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > -- > View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17803373.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by Eelco Hillenius
::
Rate this Message:
> However, I am *in no way asking* the developers to reverse the "final"
> policy. We actually relaxed that way more as we felt more confident about Wicket's API and as motivated requests came in. Personally, I think using final or not should be a deliberate choice (not automatic). If you never use it, you can arrive to that evolutionary dead-end pretty quickly (or indeed will have to break clients all the time), but if you over-use it, your framework will lack flexibility. Anyway, IF you stumble upon a final in a place where you'd like to see it go, you can always send a motivated request for that. We've typically been willing to remove finals when a good motivation was given. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Making Component easier to Generify
by igor.vaynberg
::
Rate this Message:
On Thu, Jun 12, 2008 at 9:00 AM, Brill Pappin <brill@...> wrote:
> That is the most compelling argument I have ever heard (maintainability > going forward). > saying "i like this by default" as most have done is no argument at all :) i suppose whenever you write any method that is consumed by hundreds of other developers you put a lot of thought and analysis into all the usecases for which those hundreds of developers will override this method. you think of all the corner cases, and all the things that can go wrong. you do all this by default right? no, you dont? then it is much better to make the method final by default, and once you have done all of the above and made sure that it will all work then remove the final. -igor > > However I disagree "best" is final by default... it should be the other way > around, where things are only marked final if there is a good and immediate > reason to do so. > > Although the debate is long and about as convoluted as the debate of > hungarian notation was, personal experience suggests that everything final > causes more problems than it's worth (I consider the Quartz API to be poor > for that reason also). > > However, I am *in no way asking* the developers to reverse the "final" > policy. its working, and working fairly well. I think I may have started a > thread here that is less than productive and unless others feel that there > needs to be a debate on the issue, I'll let it drop. > > - Brill Pappin > > On 12-Jun-08, at 11:50 AM, Zappaterrini, Larry wrote: > >> It is not about assuming anyone is an idiot. It is about preserving >> maintainability and allowing an API to evolve without breaking client >> code. The best approach is to mark members as final unless there is a >> compelling reason not to. Final is a safeguard for APIs to know what >> behavior is guaranteed to persist as development and evolution of the >> API is carried out. Occasionally a user can come up with a good argument >> for removing the final restriction and makes their case, affecting a >> change. >> >> It is very easy to create an evolutionary dead end for an API by >> allowing everything to be overridden. So either deprecate and start over >> or risk breaking client code and have your users hate you for it :) >> >> -----Original Message----- >> From: Brill Pappin [mailto:brill@...] >> Sent: Thursday, June 12, 2008 11:09 AM >> To: users@... >> Subject: Re: Making Component easier to Generify >> >> I understand the reasoning, however I think "best practice" can be >> debated. >> To use your example Swing allows the user to override quite a bit, and >> it doesn't make any (or very few) assumptions on what should and >> should not be done. >> >> I don't like API's that assume I'm an idiot and prevent me from >> manipulating them how I see fit. If I cause a bug that I have to deal >> with, thats *my* problem to resolve. >> >> In my book (and I'm not the only one) excessive use of final is an >> anti-pattern. >> >> - Brill Pappin >> >> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >> >>> >>> Brill, >>> >>> This is actually an API "best practice". Classes fall into two >>> categories: >>> ones designed for subclassing, and ones designed to be final. The >>> same goes >>> for methods. Swing is full of examples of what goes wrong when people >>> override methods in classes that haven't been designed with >>> subclassing in >>> mind. >>> >>> Gili >>> >>> >>> Brill Pappin wrote: >>>> >>>> on removing the finals >>>> >>>> The final members are the worst thing I've had to deal with in Wicket >>>> so far. >>>> Although I understand that there may be a reason for them, they are >>>> more a hinderance than anything else and seem to be trying to >>>> "protect >>>> users from themselves". >>>> >>>> - Brill Pappin >>>> >>>> >>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>>> >>>>> >>>>> >>>>> Have you considered moving from subclassing to composition in Wicket >>>>> using >>>>> Callable<T>? >>>>> >>>>> Currently it is quite common for developers to subclass a component >>>>> in order >>>>> to override isVisible() and other properties. I am proposing that >>>>> instead >>>>> the component classes become final and properties may only be set >>>>> using >>>>> setter methods. The setter methods would take Callable<T> instead of >>>>> T, so >>>>> for example setVisible(boolean) would become >>>>> setVisible(Callable<Boolean>) >>>>> >>>>> The benefit of this approach is that you could introduce static >>>>> factory >>>>> methods to the Wicket components which would make them much easier >>>>> to use in >>>>> their Generic form. You could then introduce various helper >>>>> classes to >>>>> create Callable<T> for constant values, such as >>>>> Callable.valueOf(true) would >>>>> return a Callable<Boolean> that always returns true. >>>>> -- >>>>> View this message in context: >>>>> >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo >> ur-take-on-generics-with-Wicket-tp17589984p17792488.html >>>>> >>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>> >>>>> >>>>> >> --------------------------------------------------------------------- >>>>> >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >> >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo >> ur-take-on-generics-with-Wicket-tp17589984p17800710.html >>> >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> ______________ >> >> The information contained in this message is proprietary and/or >> confidential. If you are not the >> intended recipient, please: (i) delete the message and all copies; (ii) do >> not disclose, >> distribute or use the message in any manner; and (iii) notify the sender >> immediately. In addition, >> please be aware that any message addressed to our domain is subject to >> archiving and review by >> persons other than the intended recipient. Thank you. >> _____________ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
RE: Making Component easier to Generify
by lzappaterrini
::
Rate this Message:
Could I dig this one back up then ;)
http://www.nabble.com/Creating-Custom-Form-Components-td16159841.html#a1 6159841 Basically my request was to remove final from FormComponent.add(IValidator...) to aid in creating custom form component subclasses based on precedent with Component.add(IBehavior...) -----Original Message----- From: Eelco Hillenius [mailto:eelco.hillenius@...] Sent: Thursday, June 12, 2008 12:51 PM To: users@... Subject: Re: Making Component easier to Generify > However, I am *in no way asking* the developers to reverse the "final" > policy. We actually relaxed that way more as we felt more confident about Wicket's API and as motivated requests came in. Personally, I think using final or not should be a deliberate choice (not automatic). If you never use it, you can arrive to that evolutionary dead-end pretty quickly (or indeed will have to break clients all the time), but if you over-use it, your framework will lack flexibility. Anyway, IF you stumble upon a final in a place where you'd like to see it go, you can always send a motivated request for that. We've typically been willing to remove finals when a good motivation was given. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... ______________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14 - 15 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
