<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Gavin,<br>
<br>
Thanks for the comments. I hope this has also shed some light after the
discussion of yesterday ... <br>
<br>
The fact that (and *where*) the specification is clear *to me* should
have been already obvious whenever I said: The spec says <stuff>
here and here's how I read it ..., but since there were other
interpretations, I summarized the outstanding open points and
subsequent explanations, hoping to have them confirmed/rebuked and thus
move on. There are a couple of outstanding issues regarding Decorators
in
Weld itself, and the goal was to make sure that we solve them according
to the spec.<br>
<br>
Otherwise, please see my own notes below:<br>
<br>
Gavin King wrote:
<blockquote
cite="mid:db199550912062331q5ca59c7ci80fbef4b3fedca8d@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Dec 7, 2009 at 2:04 AM, Marius Bogoevici <a class="moz-txt-link-rfc2396E" href="mailto:mariusb@redhat.com"><mariusb@redhat.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Overall, it seems like there are two competing restrictions at play: that a
decorator can decorate only methods defined on the decorated types (so
methods which are not on the decorated types will be ignored) and it can
decorate only beans which are injectable as delegates.
</pre>
</blockquote>
<pre wrap=""><!---->
I don't understand how these restrictions are competing, and I don't
understand your doubt.
</pre>
</blockquote>
Competing is a *very* bad choice of a word. I meant complementary and
orthogonal, not conflicting. We are on the same page, and that should
be made clearer by reading further.<br>
<blockquote
cite="mid:db199550912062331q5ca59c7ci80fbef4b3fedca8d@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">It should be noted that, according to Mark, quoting Pete (and I can see the
same in the code) - Weld does not look at the interfaces implemented by the
@Decorator bean in order to retrieve the decorated types, but it infers them
from the type of the delegate.
</pre>
</blockquote>
<pre wrap=""><!---->
That definitely doesn't sound right to me. That's not what the spec
says. The delegate might implement some interface that is not
implemented by the decorator, and is hence not a decorated type.
</pre>
</blockquote>
Pete agrees with this. I agree with this (see the part in the original
message where I say "I personally think this violates 8.1, but Pete -
in CC - knows better what are the reasons for this"). Matter solved, I
guess.<br>
<br>
<blockquote
cite="mid:db199550912062331q5ca59c7ci80fbef4b3fedca8d@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Now, it may happen that a method is defined on the decorator and the target
class, but not on any type implemented by the decorator - according to a)
and 8.1.3, it won't be used to decorate anything. But in Weld, for example,
since the decorated types are inferred from the @Delegate, it will be used
for decoration anyway,.
</pre>
</blockquote>
<pre wrap=""><!---->
If true, that would be a bug. That is not what the spec says. The spec
is the source of truth here, not Weld!
</pre>
</blockquote>
Agreed - see above.<br>
<blockquote
cite="mid:db199550912062331q5ca59c7ci80fbef4b3fedca8d@mail.gmail.com"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">The main question raised by Mark during the discussion was what is the use
for having the Decorator implement an interface, when for practical
purposes, the decorated types are indicated by the delegate type.
</pre>
</blockquote>
<pre wrap=""><!---->
No, they are not. The delegate attribute may implement additional
types that are not decorated types. And this is *useful*.
</pre>
</blockquote>
Yes, I think the same, as per below ...<br>
<blockquote
cite="mid:db199550912062331q5ca59c7ci80fbef4b3fedca8d@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Furthermore, if a decorator decorates more than one type/interface, what is
the type of the injected delegate?
</pre>
</blockquote>
<pre wrap=""><!---->
It must be a subtype of all the decorated types. The spec says this
*explicitly*.
</pre>
<blockquote type="cite">
<pre wrap="">The only possible solution now is a type
which implements/extends both interfaces, which means that only a bean of
that class or a subclass of it (including implementors if we're talking
about an interface) can be decorated. Apparently, this is possible because
of the gap in the specification that Gavin mentioned yesterday, which allows
concrete types to be delegates.
</pre>
</blockquote>
<pre wrap=""><!---->
An interface can be a subtype of other interface types. I really don't
get your point.
</pre>
</blockquote>
<br>
<blockquote
cite="mid:db199550912062331q5ca59c7ci80fbef4b3fedca8d@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">If the gap was closed by eliminating
concrete classes, then you can't have a decorator that decorates more than
one interface.
</pre>
</blockquote>
<pre wrap=""><!---->
Definitely not true.
interface X extends A,B {}
</pre>
</blockquote>
Now, here I got carried away, apparently against my better judgement
:), considering that if your delegate is X, the decorator type might be
X as well. But this is not a restriction (unless there
is no X to begin with) and X may also extend C which you wouldn't want
to get decorated.<br>
The concrete class bit was added in the context that there may be no X
to begin with (as
in a lot of cases, classes might define interfaces directly rather than
defining a superinterface). Overall, I should have known better, since
this exactly the
point I make below, so what you may just have heard is a slap over
one's head ;)<br>
<br>
<blockquote
cite="mid:db199550912062331q5ca59c7ci80fbef4b3fedca8d@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">The delegate type restricts the eligible beans anyway (only beans that
implement/extend this class are eligible), but why is then necessary to
indicate a number of interface types which can be decorated? My take on this
is that you may not want to decorate all methods on the delegate, only
certain methods and requiring the decorator bean to state the interfaces it
wants to decorate can be used for that purpose.
</pre>
</blockquote>
<pre wrap=""><!---->
Right.
</pre>
<blockquote type="cite">
<pre wrap="">But Mark has a point here,
that you can achieve the same result by just not implementing those methods,
so the requirement for the decorator to implement certain interfaces could
be considered superfluous.
</pre>
</blockquote>
<pre wrap=""><!---->
You've really, really lost me here. WTF would I not want to implement
the interface? Aside from this just being a totally normal and natural
thing to do, this makes my code typesafe (when I add @Override), and
lets my IDE fill in the method signature for me.
Suppose the interface X declares a method void foo(), and I'm going to
implement that same method on a class D (my decorator). Why would I
not want to say D implements X? How the hell can the CDI impl be sure
that this method named foo() is actually the method X.foo(), and not
some other method that just happens to have the same name? This is not
fucking Ruby. Java is a statically typed language. We identify methods
by type+name+signature. Not by name alone.
What exactly are you trying to achieve here? What is wrong with having
a decorator implement the interface it is intercepting? Why would I
ever want to do it any differently?
</pre>
</blockquote>
No, I can see your arguments. Mark has raised the same issue several
other times, I just added this here for having the laundry list of
problems complete. <br>
<br>
<blockquote
cite="mid:db199550912062331q5ca59c7ci80fbef4b3fedca8d@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Let's add Pet, an interface and have Cat implement it
class Pet { String getRegistrationNumber()};
(ASSERTION 2) The set of decorated types consists of the interface Pet.
</pre>
</blockquote>
<pre wrap=""><!---->
Not correct. Not unless CatDecorator implements Pet.
</pre>
</blockquote>
Yes, I missed that :|.<br>
<br>
<br>
</body>
</html>