I have to /strongly/ disagree here. There are several points I want to
get across. And I hope that this discussion will soon stop, as we need
to work on adding core functionality, instead of aimlessly discussing
the merits of Interfaces. It has already taken too much of my time,
mainly because of the tone of the discussion implying that the Wicket
team is incompetent. I /really/ don't like that tone.
We make careful considerations when designing and developing this
framework, and have to balance a lot of interests, among others (the
future of) our ability to work on Wicket and the ability to provide YOU
as the user with additional features.
Like Jonathan said in his discussion with Eelco, interfaces are very
difficult to evolve. We, as framework builders, find that we need the
flexibility provided to us by using the inheritence idiom, instead of
implementing interfaces. I read, for the umptieth time, point 16 in
Effective Java by Joshua Bloch. This point is titled 'Prefer interfaces
to abstract classes'. And Joshua makes the case for using interfaces
instead of using inheritence. This chapter is quite clearly inspired by
the collections package.
I quote the reverse side, also in this chapter here. This is the
trade-off we, as the framework builders and maintainers of Wicket, make:
Using abstract classes to define types that permit multiple
implementations has one great advantage over using interfaces: *It is
far easier to evolve an abstract class than it is to evolve an
interface.* [...]
It is, generally speaking, impossible to add a method to a public
interface without breaking all existing programs that use the
interface. [...]
Public interfaces, therefore, must be designed carefully. Once an
interface is released and widely implemented, it is almost impossible
to change it. You really must get it right the first time.
- Joshua Bloch, Effective Java p88 (emphasis by the original author)
Note that if we were to use an interface for Page here, we basically
made it impossible for us to evolve the Page class, without breaking a
lot of stuff out there.
In this discussion Peter mentioned Hibernate as an example framework.
Hibernate /does not/ compare to Wicket. Hibernate is a utility framework
in that you normally don't have to extend anything from the Hibernate
packages in order to be able to use it. I have yet to meet anyone who
implemented his own Session, Query or Criteria object.
Wicket is a component framework which thrives on extensions. Everything
on a web page and the web page itself in Wicket is a component. In order
to work with those components, Wicket needs more information and needs
correct meaning in the right places. *A LOT* of thought has gone into
providing extension points through inheritence.
Wicket is meant to be extended by creating your own components.
Depending on your needs, you can extend at any level in the hierarchy,
but the Wicket core is always certain that the components behave in the
intended manner.
In a public framework it is always beneficial to provide interfaces
for users to extend, even if you have abstract convenience classes to
speed development.
No, Wicket isn't about convenience classes to speed development. Wicket
/is/ the component *hierarchy*.
Having interfaces have never "broken" a framework that I'm aware of.
But they have stooped development of that framework. An interface is
cast into concrete. Once you have it, you can't change it. Period.
What, exactly is the harm in having an IPage interface in the
framework? If users don't implement the contract of the Page with
the framework, it isn't going to work.
Interfaces don't give a contract for behaviour. Our components are well
behaved within the context of Wicket. This behaviour is what makes
Wicket tick. It is what brings you the richness of our components.
Implementing some public interface doesn't give you the intended
behaviour. You'd still have to extend WebPage in order to behave within
the context of Wicket.
How do you envision having an IPage interface help our users? What kind
of new implementation would you provide that will work seemlessly with
Wicket without having the internal knowledge of how pages should react?
The only thing I can see now that would actually be a new implementation
of the Page concept is WapPage. But the WAP protocol utilizes a rather
different request cycle, as far as I know, and /really/ has a different
component hierarchy. So mixing WapPage and WebPage will not be a good thing.
Perhaps when Wicket has reached 2.0 or so when we understand where
Wicket has brought us, we will utilize interfaces to the fullest, but
until then, we need the flexibility to be able to implement new features
into our framework. Currently it is not clear what the interface should
look like and I don't see this clarifying itself in the foreseeable future.
Martijn
Vince Marco wrote:
I've got to go with Peter on this one. In a public framework it is
always beneficial to provide interfaces for users to extend, even if
you have abstract convenience classes to speed development.
While I agree with Jonathan that larger interfaces are problematic
and restrictive, that's not the only criterion for good interface
design. You also need to balance that with the number of interfaces
presented to the developer. It seems to me that a Page is a visible
construct of the browser and HTTP request-response cycle that
developers are familiar with. I wouldn't underestimate the value of
a Page interface for users, especially since one of the main classes
you are asking them to subclass is a WebPage. I see value in an
IPage interface, perhaps comprised of a number of sub-interfaces.
And sure users could extract their own interfaces, but I thought that
Wicket by being a web framework, was in the business of doing things
like that for users.
What, exactly is the harm in having an IPage interface in the
framework? If users don't implement the contract of the Page with
the framework, it isn't going to work. If they do, then Wicket will
suit their custom needs. It doesn't mean the WebPage class is going
away. Having interfaces have never "broken" a framework that I'm
aware of. Changing interfaces can determine incompatibilities
between versions.
My 2 cents.
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
