Let me understand you here. You want to make several points and then
you want the discussion to go away. I can understand you wanting to
make points, OR wanting the discussion to go away, but isn't pursuing
both just asking a bit too much. I suppose you could have just asked
to have the last word, but it probably wouldn't have worked either. :-)
To be clear, changing the API of an abstract class is just as
damaging and difficult as changing an interface. They have the same
effect. It is not flexibility you gain from using the abstract
class. It is ease-of-use. Developers can merely subclass your
abstract class to gain its advantages. An interface would require
some way of accessing your implemented behavior, other than through
the interface itself, because there is no code there. (ie. a factory
or container to inject the actual behavior).
It is a good first step for Wicket, at a time when developers need
the framework to be easy. Good job. However, it would be entirely
possible to have the framework provide developer page subclasses
access to one (or multiple) delegates containing the behavior
currently in the abstract class, enabling multiple behaviors to be
supported. It could trigger the various behaviors merely by
implementing the appropriate interface, which the framework would use
as a flag to determine the appropriate delegate implementation to
invoke at runtime. Very flexible, and no loss of ease-of-use.
I don't think that Wicket needs this now, but I am fairly certain
that if you don't intend Wicket to have its day and go by the
wayside, eventually this level of flexibility, and this type of
design should be considered, at least in specific places.
Cheers,
Vince Marco
President, Enterprise Frameworks, Inc.
On Jul 16, 2005, at 5:31 PM, Martijn Dashorst wrote:
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.
-------------------------------------------------------
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
