Vince Marco wrote:
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. :-)
I guess not. What we want to make clear is that, though usefull at
times, we don't want to have a style discussion every few weeks. There
are books written about it, blogs dedicated to it, and in the end there
are allways pros and cons.
We also wanted to get the message across that we really try to follow
best OO practices, and actually did think through a lot of what is in
Wicket. Not everything is visible because we have a lot of offline
discussions, but we try to come up with the best API we can write. So
debates like these (and we've had the 'final' keyword, the 'I' for the
interface, 'wicket.x' for package names) are like, well guys, you
obviously didn't think it through, but here's how you should do it,
while we've been through the whole decision making proces ourselves.
Still, that wouldn't be a problem, as I think programmers stop learning
when they can't deal with criticism. But I also think that if we try to
make clear that we made a conscious design decision about something, and
the only arguments against that are stylish ones (because still I
haven't heard an argument what practical thing you couldn't do with a
page without having an interface), it would be chique to let the
discussion rest (or start some general programming thread on TSS or
something). It is not a matter of wanting to have to last word. It is a
matter of wanting our time to be productive. Writing this email will
take me about one hour, so the whole discussion dide cost us many hours
that could have been used for other (Wicket) things.
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).
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.
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.
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.
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.
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.
Regards,
Eelco
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
-------------------------------------------------------
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
