Re: [weld-dev] Discussion on Delegate/Decorated types
On Mon, Dec 7, 2009 at 3:48 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
"The delegate type of a decorator must implement or extend every
decorated type"
Right. This is correct. I don't understand the doubt.
plus
"The decorator intercepts every method:
• declared by a decorated type of the decorator
• that is implemented by the bean class of the decorator."
Also correct. Again, I don't understand what's wrong here.
So this is why I assumed that the decorator type (the X thingy
defined with @Decorate
XDec implements X) defines the beans which are decorated.
No, the above describes which methods are intercepted, not which beans
are decorated.
And please re-read the preamble of chapter 8, which many people read
as the exact same:
"A decorator implements one or more bean types and intercepts business method
invocations
of (all!) _beans_which_implement_those_bean_types_."!
That is in a chapter preamble, so it is descriptive, not prescriptive,
just like probably everything else in chapter preambles.
And it conspicuously does *not* say "all", you added that word in
yourself. If I had wanted to say "all", I would have said "all" (or
"every"). I'm very careful about things like that. The fact that I did
not say "all" should give you a clue that maybe that is not what I
meant!
I read nothing from getting the delegated types (= in my read the
bean types which should get
decorated) from the @Delegate. But this is obviously the only way it could work.
But this is *very* well defined in section 8.3! 8.3 leaves absolutely
no room for doubt on how this works.
Anyway. We are now d'accord (hope so at least) that the decission
which beans get decorated
is: every bean which is assignable to the type of the @Delegate.
Not quite. Read 8.3. It says:
"The bean is assignable to the delegate injection point according to
the rules defined in Section 5.2, “Typesafe resolution” (using Section
8.3.1, “Assignability of raw and parameterized types for delegate
injection points”)."
There is no need to check the decorator type (the X of @Decorator
XDec implements X),because that must always be a subset of the @Delegate (see 1st sentence
in 8.1.3)
Which imho makes the decorator type basically useless - thus our question.
Nononono! A method named foo() of a class C is NOT the method X.foo()
unless C implements X. I don't understand why I'm not getting through
on this. I don't know how else to say it.
To repeat the argument: why using an interface to restrict the
decorator to a few functions?
Simply don't implement the functions you do not like to decorate! In fact the 2 parts
are exactly
_not_ orthogonal things because 1) is a pure subset of 2)!
No. No. No.
This is Java, not Ruby or SmallTalk. Seriously. *Think* about it!
Regarding the @Override argument. That's nice for some IDEs, but
is Retention.SOURCE thus
will get discarded by the compiler and helps us nothing at deploy time in the
container...
Did I mention anything about deployment time?! I talked about
compile-time type safety.
To clarify this: we are surely talking about not only the fn-name but
the whole signature of a
function!
Which is not enough to identify a method in Java! It also matters what
type declares the method!
Seriously, I don't understand how we can possibly be arguing about this.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org