I was interested in the technical problem behind "I can't do this if it is not an interface." ..
Martin Grigorov Wicket Training and Consulting On Wed, Feb 26, 2014 at 5:33 PM, tetsuo <ronald.tet...@gmail.com> wrote: > 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 > > > > >> > > > > >> > > > > > > > > > > > > > > >
