No, we really don't agree here. It does make a big difference. For an interface to be usefull, you have to extract a lot of what would otherwise have been implementation details: 1) Everything in the interface is public. So methods like initModel (), detachModel(), onBeginRequest() would have to be public, while we decided that these methods should be protected.
You don't need to expose any methods you don't want overridden. You don't lose any control with an interface. In fact, it can be methodless and still be effective. This is certainly cleaner than an abstract class with final methods.
2) A lot of behavioural things must be pulled out to interfaces for them to be meaningfull. An example of this is the checking of whether all components rendered. This is now implemented in Page.checkRendering() and the render logic of Page. When we would support a page interface, we would have to think of some explicit way of putting this in our inteface. The reason for this is that we give users the configuration option to have render checking done, and configuration is one of the main general Wicket contracts. We now force this part of the contract.
Again an improper assumption. If you wrap the user class (implementing the Page interface) with an implementation wrapper -- decorator, actually -- (on Application.add()), then you don't need to expose any methods you don't want the user to have to implement. The wrapper class can contain the Page.checkRendering() and either look for a method in the user subclass, or just detect an interface flag (ie. ICheckRender). You can do quite a lot through Reflection, WRT using interfaces at runtime without adding methods. An additional benefit is that the user just needs to implement the desired interfaces and the appropriate implementation classes can be wrapped around their class at runtime. I would envision a IPage interface with few, if any, methods -- therefore not requiring the user to implement anything.
3) going further on 2), introducing interfaces would mean that, besides the fact that adding methods to an interface break clients whereas adding methods to an abstract class don't, in our new situation it would be more difficult for us to change what we currently consider implementation details, as many of those former implementation details would have been extracted to interfaces.
Again, you are assuming that you HAVE to add methods to the interface to be effective. There are other ways of making the interface approach very versatile WITHOUT breaking user's subclasses (ie. adding methods). Additional methods can be added to mixin interfaces as an example. I don't think you and I are that far apart WRT interfaces, but you have made some assumptions WRT their use that limit their value needlessly and do make them intrusive to users. Given those assumptions, I back your design decisions entirely.
Considering is allright. But give us real world problems cq usuages first. If there really are good reasons, I am sure we would consider it. I think our track record of honouring user's wishes is pretty good. But we also want to have the API as tight as it can be, and we just need darn good reasons to change our core assumptions.
The Wicket team certainly has made your stance known. I will not post anymore design ideas to this group. If the mail is overwhelming you, you might consider a forum. Or just dump the emails that are "wasting" your time. I've put forth some good ideas that you guys seem to be "against". That's OK, it's your product. I'm not just thumping the interface bible here, and my reasoning for posting this into the Wicket forum (instead of TSS), is that this you guys have produced a very clean API and I thought you might be open to these ideas to make Wicket even better. I can see that is not the case. Welcome to open source.
Cheers, Vince ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
