Building a framework is not only about giving as much choice as
possible. Like stated before there are lots of other reasons why we
don't want to use interfaces here. If people want it, file an RFE with
/a very good convincing reason other than style/ and we may start up a
discussion on this later. For now, this discussion ends here. Period.
Eelco
Gili wrote:
I think you're missing a bit point here: the reason Sun doesn't
use interfaces for some Swing components is that for them it is
certainly true they cannot break backwards compatibility. We plan on
routinely doing this in 1.x and x.0 releases so it's really not such a
big deal. The only person who would get affected is someone who is
extending a Page in the first place and quite frankly my guess is that
99% of users do not. For those who wish to extend we are offering
interfaces or abstract classes to implement/extend. It is their choice
because they will be the ones affected, not the guys working on the
core. If they prefer interfaces so be it <shrug>
Gili
Eelco Hillenius wrote:
Nbr 1 reason currently: because no-one yet came with a convincing
case of why we would need it. All developers are against it (haven't
heard from Chris and Juergen, but my guess is we're on the same line
here), and we want to end this discussion now. Btw, a remark that
Johan made offline: it would be kind of the same discussion as why
Swing's Window or SWT's Shell is not backed by interfaces. It's a
design decision that was made with what we think are good reasons.
If people really think it is important for them, they can add an RFE
for 1.2 or up. That RFE should include at least one really convincing
use case of why the current set up would be limiting for them, and
why they couldn't achieve the same goals by simply subclassing (and
maybe attach their own interfaces).
Eelco
Gili wrote:
Hmm, maybe this isn't an all or nothing case. Why can't a Page
consist of many smaller interfaces that it implements?
Gili
Eelco Hillenius wrote:
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.
I would agree with often, not with allways. I think in Wicket's
case, there is too much behaviour to create a good interface from.
Again my question: what would that interface look like? If I look
at the page interface of one of the frameworks we are competing
with, I see a lot of methods of which I think do not belong in a
clean interface (getThis, getThat); stuff that doesn't point to a
clear type, nor to a very specific type's behaviour.
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.
I would like to turn this discussion around. I would like to know
/why/. For what exact reasons - except for stylistic reasons - does
it add value for you that Wicket pages are backed by interfaces?
What would you do that you couldn't do with subclassing?
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.
In being a framework, Wicket tries to provide a lot of flexibility
in some areas, while limiting it on purpose (for reasons of
evolvability, and having a tigh API with shallow conceptual
serface) in other areas. Jonathan made a design decision not to use
interfaces, and if I had to choose now, I'd choose the same.
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.
Changing interfaces in a business system with just a few clients is
not such a big deal. However, we strife to be a framework that is
used by a lot of users, so we want to be very considerate before we
break a lot of stuff for users all the time.
But... as long as people inherit from (Web)Page, there wouldn't
still be a lot of problems, as WebPage would evolve with the
interface.
However, the big problems start when we provide an interface and
people actually begin to depend on that interface directly. My
problems with that are:
- We hide a lot of behaviour in pages and components. If we would
have to extract that behaviour to be reflected in the interface,
that would be a hard job, and it would seriously limit our options
of refactoring the internals. And we would /need/ to extract the
behaviour to the interfaces, because otherwise our interfaces would
be meaningless.
- Every interface change would break all clients that depend on the
interface immediately. Not so much the case with abstract classes,
as we have much more options of keeping things internal.
So, as I think this is really important, let me put this another
way: having interfaces for pages and components is not a good idea
because to get interfaces that are actually meaningful, and that
reflect the behaviour of what they abstract, we would have to pull
a lot of our current internal behaviour (usually our final methods)
to the public interfaces where they are not final, allways public,
and part of the complete contract that implementors have to obey.
My 2 cents.
Vince
My 2 cents too, though my opinion is very strong on this.
That doesn't mean there is no discussion possible about this, but
I'd really like to see some convincing use cases why people would
want to have such interfaces, as it would be a very big deal to the
current developers (who I think all agree on /not/ having
interfaces) to change this.
Regards,
Eelco
-------------------------------------------------------
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
-------------------------------------------------------
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
