8:04 a.m.
Gavin,
Mark and I had a discussion tonight about decorators, trying to clarify
some aspects of the specification. It would be great if you could review
the statements/comments/use cases described below and indicate what is
correct, what isn't, how will the spec address this in the future, etc.
It is a long message, but I tried to err by being too verbose rather
than risking to leave something out.
So, the main themes of the discussion were:
a) what are the decorated types of the decorator how do we identify them
and what role do they play?
b) what are the beans that a decorator can decorate?
c) reviewing a few examples that illustrate the various points being made.
So, I think that a) could be answered by looking at the preamble of
chapter 8, which states that "A decorator implements one or more bean
types and intercepts business method invocations of beans which
implement those bean types. These bean types are called decorated types"
and 8.1 which states that "The set of decorated types of a decorator
includes all interfaces implemented directly or indirectly by the bean
class, except for java.io.Serializable"
The role of decorated types is laid out by 8.1.3 which states "The
decorator intercepts every method: • declared by a decorated type of the
decorator [...]"
b)On the other hand, I read 8.3 as saying that a decorator can decorate
only beans which are injectable as delegates ("The bean is eligible for
injection to the delegate injection point according to the rules defined
in Section 5.3, “Typesafe resolution”.")
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.
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. (I personally think this
violates 8.1, but Pete - in CC - knows better what are the reasons for
this).
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,.
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.
Furthermore, if a decorator decorates more than one type/interface, what
is the type of the injected delegate? 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. If the gap was
closed by eliminating concrete classes, then you can't have a decorator
that decorates more than one interface.
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. 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.
c) Samples
Let's look at an example provided by Mark:
class Cat { String getName() {return "";}};
class AngoraCat extends Cat { boolean getHairLength() {return true}}
class SiamCat extends Cat { };
@Decorator CatDecorator { @Delegate Cat c; String getName() {
log.info("something"); return c.getName(); } }
Now, looking at this sample it seems like:
(ASSERTION 1) In the sample above there are no decorated types,
therefore no actual decoration takes place.
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.
Now let's consider the following two decorators:
@Decorator PetDecorator implements Pet {@Delegate Pet p; String
getName() { log.info("something"); return c.getName(); }}
@Decorator CatDecorator { @Delegate Cat c; String getName() {
log.info("something"); return c.getName(); } }
(ASSERTION 3) With the modification above, both PetDecorator and
CatDecorator apply to all types of cats, but PetDecorator also applies
to Pets which are not Cats
Now, if we had:
interface Cat { String getName();};
class SiamCat implements Cat, Pet { };
class RussianForestCat implements Cat, Pet { };
@Decorator PetCatDecorator implements Cat,Pet {@Delegate SiamCat c;
String getName() { log.info("something"); return c.getName(); }}
(ASSERTION 4) PetCat will decorate SiamCat but not RussianForestCat
(won't even be picked up as a decorator since it does not meet 8.3 wrt
RussianForestCat
So - Gavin, please also indicate which of these use cases is valid and
which assertions hold or not.
Mark, I tried to lay out your questions/opinions, as well as mine, as
accurate as I could. Feel free to comment/add anything you think is
relevant. I think it is important to agree on both the letter as well as
the spirit of the specification.
Cheers,
Marius