Ideally, we would have had the foresight to segregate interfaces into different packages to identify which are frozen (user interfaces expected to be implemented in user code) vs. merely compatible (allowed to add new methods).
Since everything is kind of mixed together into just a couple of packages, instead we've been using annotations for this purpose. I suppose we could sort this out (break up large packages into smaller packages), but that would really break compatibility so I'm preemptively against it. On Wed, Mar 10, 2010 at 1:00 PM, Ulrich Stärk <[email protected]> wrote: > IIRC that's something I've chatted about with Howard before and it's one of > the things he plans to do. There doesn't exist an issue though, so feel free > to add it. > > Uli > > On 10.03.2010 20:30, Joachim Van der Auwera wrote: >> >> Hi, >> >> In 5.2 some interfaces have changed compared with 5.1, for example Link. >> As methods have only been added, this should not be a problem for users >> consumers, but it is a problem for code which implements the interface. >> >> Would it not be an idea to put javadoc comments on all interfaces which >> are not intended to be implemented by tapestry users (and possible ways >> of creating instances or abstract base classes to implement) to clearly >> indicate in which cases backwards compatibility can be assured? >> >> Kind regards, >> Joachim >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
