Guillaume, you're right. Martin, sorry for the misunderstanding.
Enums can't extend any classes besides Enum. But can implement interfaces. I use Enums in lots of places, not as enums, but as singletons, because they won't be serialized, won't carry unintended references, and use virtually no memory in pages. Converters, Renderers, Validators, Models (less so of the former, since it almost always needs state). If IBehavior still existed, and didn't have so many methods, I'd use enums to implement some of them, too. But my main complaint is not specific to this issue, however. I'm more concerned about frequent breaking API changes with no practical advantage. Javascript/JavaScript, addComponent/add(Component) and the like. I'm at the point that I'm starting to feel unconfortable recommending Wicket to people, because I know an year from now they will complain that they upgraded a library and a thousand compiling errors appeared. 98% of them are very simple errors, but it's a daunting task neverthless. On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <[email protected]>wrote: > As Martijn explained all that is needed is: > - s/implements/extends/ > - remove the leading 'I' from IChoiceRenderer > > If the interface is preserved then all custom impls will have to add > implementation of the new method introduced with WICKET-663. This IMO will > lead to more work for the application developers. > > As I said: I am not against restoring the interface, just don't see its > value. > > Martin Grigorov > Wicket Training and Consulting > > > On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <[email protected] > >wrote: > > > On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <[email protected]> wrote: > > > Because... it's an unnecessary breaking change? > > > > From what I understand of your previous post, you implements some of > > your converters in Enums, which you can do because IChoiceRenderer is > > currently an interface. And you won't be able to do it if it's a > > class. > > > > Am I right? > > >
