Because... it's an unnecessary breaking change?
On Wed, Feb 26, 2014 at 9:54 AM, Martin Grigorov <mgrigo...@apache.org>wrote: > On Wed, Feb 26, 2014 at 2:52 PM, tetsuo <ronald.tet...@gmail.com> wrote: > > > +1 for keeping IChoiceRenderer. > > > > I often create Enums with a single value when I want a singleton (the JVM > > guarantees the single instance, and it takes less space in memory and > when > > serialized), and many of my custom choice renderers are like this. I > can't > > do this if it is not an interface. > > > > Why ? > > > > > > > > > > > > > > On Wed, Feb 26, 2014 at 7:45 AM, Martin Grigorov <mgrigo...@apache.org > > >wrote: > > > > > Hi, > > > > > > Igor suggested to remove the interface and I agreed. > > > For me there was no real benefit from the interface here. > > > Almost everything in Wicket uses ChoiceRenderer. > > > By using a class it is easier to add new logic. Otherwise tickets like > > > https://issues.apache.org/jira/browse/WICKET-663 will be moved to the > > next > > > major release and then forgotten. > > > > > > But I don't expect adding new methods in near future to this class so I > > am > > > not against reverting this. > > > > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > > > > > > > On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier <s...@meiers.net> wrote: > > > > > > > +1 for keeping IChoiceRenderer: > > > > > > > > Currently all renderers extend ChoiceRenderer. But EnumChoiceRenderer > > > > could be implemented on its own: > > > > > > > > public T getObject(String id, IModel<? extends List<? extends T>> > > > > choices) > > > > { > > > > if (choices.getObject().isEmpty()) > > > > { > > > > return null; > > > > } > > > > else > > > > { > > > > return > > (T)Enum.valueOf(choices.getObject().get(0).getClass(), > > > > id); > > > > } > > > > } > > > > > > > > Other implementations could do so too, so why should they extend > > > > ChoiceRenderer? An interface would be suited much better for this. > > > > > > > > Regards > > > > Sven > > > > > > > > > > > > > > > > On 02/26/2014 11:23 AM, Martijn Dashorst wrote: > > > > > > > >> While upgrading our application the biggest time sink for now was > > going > > > >> through our code base and fixing the issues that came from removing > > > >> IChoiceRenderer. While I don't mind the work (mostly search and > > > replace) I > > > >> would like to learn about the reasoning for removing the interface. > > > >> > > > >> In my previous trial Sven noticed that he'd like to see > > IChoiceRenderer > > > >> restored. I'd like to start the discussion and resolve it before we > > cut > > > a > > > >> 7-M1 release-to prevent having to go through the motions of > > > re-introducing > > > >> the interface after folks have done work to modify their code base > to > > > the > > > >> IChoiceRenderer-less situation. > > > >> > > > >> What are the pro's and con's of removing/keeping IChoiceRenderer? > > > >> > > > >> Martijn > > > >> > > > >> > > > > > > > > > >
