Say for example, the Foo class looked like:
public class Foo {
@Inject
public Foo(@Bar(name="Pete") String s) {
}
@Produces
public void produce(@Bar(name="Gerhard") String s) {
}
}
This is the kind of place where the "closure" based approach will help you.
Again, of course, it's possible imperatively, but messy imo, as you need to
iterate over a lot of stuff to get there.
On 18 Jan 2012, at 15:51, Pete Muir wrote:
> The idea behind the redefiner was to allow the use of a limited form of a
> closure to work over the class. Every annotation on the class will receive a
> callback to the function, in which you can decide how to use the annotation
> (replace, keep etc). This gives you access to the context in which the
> redefinition takes place.
>
> For example:
>
> public void redefine() {
>
> AnnotatedTypeBuilder<Foo> builder = new
> AnnotatedTypeBuilder<Foo>().readFromType(Foo.class);
>
> builder.redefine(Bar.class, new AnnotationRedefiner<Bar>() {
>
> @Override
> public void redefine(RedefinitionContext<Bar> ctx) {
> if
> (ctx.getAnnotationBuilder().getAnnotation(Bar.class).name().equals("Pete")) {
> ...
> }
> }
>
> });
>
> }
>
> I don't believe this is possible using the imperative commands (at least, not
> so concisely).
>
> I would be against dropping this feature, as I think it is useful and has a
> common precedent (e.g. common programming pattern books).
>
> On 17 Jan 2012, at 23:14, Gerhard Petracek wrote:
>
>> hi @ all,
>>
>> today i reviewed it. my findings:
>>
>> #1:
>> imo we shouldn't have public impl classes in the api module >if< we can
>> avoid it. i made a small refactoring to reduce the visibility of those
>> classes and i attached a patch which shows the suggestion at [1].
>>
>> #2:
>> i had a short talk with pete about AnnotationRedefiner. it looks like that
>> it was introduced to provide an alternative syntax to the other builder
>> methods esp. for complex cases.
>> imo we should re-visit it (esp. if there are really that many cases which
>> really benefit from it - compared to using the other builder methods).
>>
>> regards,
>> gerhard
>>
>> [1] https://issues.apache.org/jira/browse/DELTASPIKE-45
>>
>>
>>
>> 2012/1/7 Jason Porter <[email protected]>
>>
>>> I have the classes all checked into my branch [1]. Please review. I know
>>> many of them need Javadoc, so you can forget that part. Mainly the
>>> AnnotatedTypeBuilder needed many classes that were in Solder Impl. As I
>>> believe AnnotatedTypeBuilder is pretty helpful for everyone doing CDI
>>> Extension development I put them all in api, so we'll have some *Impl
>>> classes in api. If everyone is okay with that, great. Otherwise we may need
>>> to find a new place to put them as we can't put them in impl and keep
>>> AnnotatedTypeBuilder in api.
>>>
>>> [1] https://github.com/LightGuard/incubator-deltaspike/tree/DELTASPIKE-45
>>>
>>> --
>>> Jason Porter
>>> http://lightguard-jp.blogspot.com
>>> http://twitter.com/lightguardjp
>>>
>>> Software Engineer
>>> Open Source Advocate
>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>
>>> PGP key id: 926CCFF5
>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>
>
