Christophe,
I guess a part of the problem is that if I subclass from a parent class,
I might not know what private methods it has. Thus, if the superclass ends
up having a private method annotated w/ @SetupRender, and I accidentally end
up having a private method in my class w/ the same name and annotated
@SetupRender, my method isn't getting called. Sounds like a massive
violation of encapsulation principles.
Regards,
Alex K
On Wed, Sep 1, 2010 at 8:25 AM, Christophe Cordenier <
christophe.corden...@gmail.com> wrote:
> Hi !
>
> Actually as far as i remember when method have the same name, the generated
> code would simply call 'init' method without method selection in this case.
>
> Anyway, Paul should use a protected or package visibility in his case and
> call super.init() on the parent class.
>
> 2010/9/1 Alex Kotchnev <akoch...@gmail.com>
>
> > Christophe,
> > I think Paul's point is that there shouldn't be any overriding
> happening
> > : in his first case, these are private methods; hence, the @Override
> > annotation would be incorrect.
> >
> > Sounds like a bug to me.
> >
> > Regards,
> >
> > Alex K
> >
> >
> >
> > On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier <
> > christophe.corden...@gmail.com> wrote:
> >
> > > Hi !
> > >
> > > You should use @Override on overriden methods in sub-classes
> > >
> > > 2010/9/1 Paul Stanton <p...@mapshed.com.au>
> > >
> > > > I've found a strange issue with the @SetupRender annotation when used
> > in
> > > a
> > > > class hierarchy.
> > > >
> > > > Typically, in java 2 classes within a hierarchy can have the same
> > > signature
> > > > for a private method and not effect each other, so I would expect
> this
> > to
> > > be
> > > > the case when both of these private methods are annotated with
> > > @SetupRender.
> > > > Therefore the output for case 1 and case 2 (below) should be the same
> > and
> > > > print both messages "setupRender2", "setupRender1".
> > > >
> > > > However case 1 only prints "setupRender2" meaning it somehow
> overwrites
> > > the
> > > > method in it's implementing class.
> > > >
> > > > This is concerning because
> > > > 1. there should never be a requirement that a sub-class knows of it's
> > > > super-classes implementation
> > > > 2. if hierarchy does come into play, the subclass should override the
> > > super
> > > > class.
> > > >
> > > > CASE 1:
> > > > ------------------
> > > > public abstract class StartBase {
> > > > @SetupRender
> > > > private void init() {
> > > > log.debug("setupRender2");
> > > > }
> > > > }
> > > >
> > > > public class Start extends StartBase {
> > > > @SetupRender
> > > > private void init() {
> > > > log.debug("setupRender1");
> > > > }
> > > > }
> > > >
> > > > CASE 2:
> > > > ------------------
> > > > public abstract class StartBase {
> > > > @SetupRender
> > > > private void init2() {
> > > > log.debug("setupRender2");
> > > > }
> > > > }
> > > >
> > > > public class Start extends StartBase {
> > > > @SetupRender
> > > > private void init1() {
> > > > log.debug("setupRender1");
> > > > }
> > > > }
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > > > For additional commands, e-mail: users-h...@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Christophe Cordenier.
> > >
> > > Committer on Apache Tapestry 5
> > > Co-creator of wooki @wookicentral.com
> > >
> >
>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
