Sorry for the rant... The transition from 1.4 to 1.5 was awful (full of such minor breaking changes), but not so afterwards, I know I'm overreacting. Probably it's because it happened (a colleague complaining about all the compiling errors when upgrading from 1.4) last week :/
And well... it's somewhat inevitable to avoid compiling errors when evolving a framework that is strongly type-safe (which is a great plus). Sorry again. But I still like my enums, please keep the interfaces :) On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ronald.tet...@gmail.com> wrote: > > > Guillaume, you're right. > > > > Martin, sorry for the misunderstanding. > > > > Enums can't extend any classes besides Enum. But can implement > interfaces. > > > > Thanks! Now it is clear to me. > > > > > > 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. > > > > > Options: > 1) Wicket devs stop developing Wicket so the API stays stable forever > 2) application developers don't upgrade to next major version of Wicket > 3) find the golden middle. > > I think we all agree that 3) is the best for all and that we (Wicket devs) > try to follow it: > > - we use SemVer to make it easier for application developers to know when > to expect API breaks and when to not expect such > - we discuss most of the API breaks for major versions here in dev@. > If there are issues identified on time we react! Even this change has > been discussed before being made > > > > > > > > > > > > > > On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <mgrigo...@apache.org > > >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 < > > guillaume.s...@gmail.com > > > >wrote: > > > > > > > On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ronald.tet...@gmail.com> > > 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? > > > > > > > > > >
