Hi, the Eclipse API guidelines uses interfaces for what you plan to mark with @UserConsumed and they use abstract classes which need to be subclassed for the @UserImplemented case.
Extending abstract classes does not break exisitng user code as long as you provide default implementations. What do you think about this? Olli 2010/3/10 Howard Lewis Ship <[email protected]> > @UserImplemented vs. @UserConsumed > > Implemented would need very strict controls over extending the > interface (i.e., never). > > UserConsumed would be more generous, as user code is not expected to > extend the interface, just import/inject it. > > On Wed, Mar 10, 2010 at 2:09 PM, Thiago H. de Paula Figueiredo > <[email protected]> wrote: > > +1 to a @MethodsCanBeAddedInTheFuture (or a better name) annotation. > > > > On Wed, 10 Mar 2010 19:00:39 -0300, Howard Lewis Ship <[email protected]> > > wrote: > > > >> 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] > >>> > >>> > >> > >> > >> > > > > > > -- > > Thiago H. de Paula Figueiredo > > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and > > instructor > > Owner, software architect and developer, Ars Machina Tecnologia da > > Informação Ltda. > > Coordenador e professor da Especialização em Engenharia de Software com > > Ênfase em Java da Faculdade Pitágoras > > Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate > > Sócio, Ars Machina Tecnologia da Informação Ltda. > > http://www.arsmachina.com.br > > > > --------------------------------------------------------------------- > > 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] > > -- og
