[weld-dev] Discussion on Delegate/Decorated types

Gavin King gavin.king at gmail.com
Mon Dec 7 10:49:21 EST 2009


On Mon, Dec 7, 2009 at 3:48 AM, Mark Struberg <struberg at 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 at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org



More information about the weld-dev mailing list