+1
Though in the case of @UserConsumed, it would be useful if the javadoc
would indicate how a user can obtain an instance.
Kind regards,
Joachim
Howard Lewis Ship wrote:
@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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
