Vince Marco wrote:
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.
Though these methods - being non public - can be seen as implementation
details, they are important details; if we need initModel for further
assumptions in our framework. As we need it to be there, we must extract
it in any interface we would make.
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.
The point is that, as an interface is implementation-less, we can't
force behaviour. The only things we can force is what methods/ typing is
in there, and make clear points about the contract. Having it
implemented with final methods in an abstract class absolutely
guarantees this it is there, while working with an interface much
depends on how far you were able to define your functionality in the
exported contract. This is just much harder (thus more work). Look at
the spec driven API's as an example that there are allways things that
aren't clearly enough defined, resulting in implementation nuances
between implementations.
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.
We're absolutely not against improvements. Especially not the kind of
improvements that help people work with Wicket more effectively.
Stylistic improvements can be very worthwhile too, but allways have to
go through debates like these, which I don't particularly enjoy on a
project specific list, and which might scare users away due to its harsh
tone. But maybe I'm just thinking that.
Anyway, I do thank you for seriously trying to get your point across too,
Eelco
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
-------------------------------------------------------
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
