yes private or package scope methods should always be called
The names of the methods don't matter then.
If they are public of protected only call one of them.
johan
On 10/29/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 10/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> if you ask for getMethods() you only get one.
> But you must ask for declared methods (else you only get the public
onces)
> and declared returns only from the class itself. so yes then when you
walk
> over the hierarchy you will get 2...
exactly, what i can do is use a treeset with a comparator that looks
something like this:
compare(Method a, Method b) {
if a.isprivate()||b.isprivate return a.getname().compareto(b.getname());
return 0;
}
that should prob do it, but should we?
-igor
johan
>
>
> On 10/29/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > yes i am sure, what you actually get is
> >
> > Method[] { A.init(), B.init(); }
> >
> > so then i call them both, but because B overrides A.init() B.init() is
> > called twice.
> >
> >
> > as i said it is partially user error because B.init() should not be
> > annotated with @OnAttach, but we need to decide whether we want to
> handle
> > that error for the user.
> >
> > -igor
> >
> >
> > On 10/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > >
> > > by the way are you sure you get them twice when scanning for them?
> > > Because if you ask just getMethods() of a class it will turn out
once.
> > > (except when the return type difference then you get 2 methods with
> the
> > > same
> > > name params)
> > >
> > > johan
> > >
> > >
> > > On 10/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I guess when scanning you get a method object.
> > > > Why not make a hash (method name and params) and throw that in a
> > hashmap
> > > > so that they are all unique?
> > > >
> > > > johan
> > > >
> > > >
> > > > On 10/29/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > nothing is ever simple, sigh :)
> > > > >
> > > > > there is a usecase which might cause some nasty sideeffects
> > > > >
> > > > > consider
> > > > >
> > > > > class A extends Page {
> > > > > @OnAttach protected void init() { System.out.println("A.init
();");
> }
> > > > > }
> > > > >
> > > > > class B extends A {
> > > > > @OnAttach protected void init() { System.out.println("B.init
> ();");}
> > > > > }
> > > > >
> > > > > when you use B and it gets attached the output is:
> > > > > B.init();
> > > > > B.init();
> > > > >
> > > > > this is because when scanning for annots we will see A.init()
and
> > > B.init
> > > > > ()
> > > > > and then call them both, but because B.init() overrides A.init()
> > when
> > > > > A.init()
> > > > > is invoked it calls B.init()
> > > > >
> > > > > i would say this is a user error - since B.init() overrides
A.init
> ()
> > > the
> > > > > method should not be annotated with @OnAttach.
> > > > >
> > > > > so the question is do we leave it like that, or do we implement
> some
> > > > > more
> > > > > complex scanning and try to figure out if any method overrides
are
> > > going
> > > > > on
> > > > > and exclude those. i dont think java's reflection allows us to
do
> > this
> > > > > out
> > > > > of the box.
> > > > >
> > > > > what do you all think?
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 10/27/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > we have a couple of great candidate callbacks to be
implemented
> > with
> > > > > > annotations instead of template methods. namely
onattach/detach,
> > > > > > onbegin/endrender
> > > > > >
> > > > > > what makes them great candidates is this
> > > > > >
> > > > > > 1) when implementing one you must always call super()
> > > > > > this is not _always_ true. when extending a core component you
> > dont
> > > > > need
> > > > > > to because we have our own internalattach() we can use and
> > > onattach()
> > > > > is
> > > > > > just an empty template.
> > > > > >
> > > > > > but when extending a non-core component you must call super()
> > > because
> > > > > you
> > > > > > never know if that component uses it or not and it is very
very
> > > > > unlikely
> > > > > > that it is a behavior you want to override
> > > > > >
> > > > > > 2) implementors of onattach(), if they are good, will make it
> > final
> > > > > and
> > > > > > provide another breakout template to ensure their onattach
code
> > > cannot
> > > > > be
> > > > > > messed with. this leads you to have
> > > > > >
> > > > > > public final void onAttach(){ dosomething(); onAttach2(); }
> public
> > > > > void
> > > > > > onAttach2() {}
> > > > > >
> > > > > > this is the general java pattern that i find very ugly
> personally,
> > > > > take a
> > > > > > look at our Component.internalAttach() impl :)
> > > > > >
> > > > > > so what i propose is that we provide some annotations
> > > > > > @OnAttach @OnDetach @OnBeforeRender @OnAfterRender
> > > > > >
> > > > > > users can annotate any number of methods with these and have
> them
> > > > > called.
> > > > > >
> > > > > > im sure there are other places that can benefit from this, but
> for
> > > now
> > > > > we
> > > > > > can cleanup the mess that is internalAttach(),
> internalOnAttach()
> > > > > > onAttach(), etc
> > > > > >
> > > > > > of course this is wicket 2.0 only
> > > > > >
> > > > > > -Igor
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>
