deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS] [DELTASPIKE-8] @Veto
Date Wed, 28 Dec 2011 00:24:50 GMT
+1 for @Unmanaged
(+1 for @Exclude if it's the only alternative we can agree on)

regards,
gerhard



2011/12/28 Marius Bogoevici <marius.bogoevici@gmail.com>

> As if we didn't have enough alternatives, here's another one that popped
> up while discussing with Gerhard the relative merits of @Veto and @Exclude:
>
> @Unmanaged
>
> I think that this solves a few problems that we currently have:
>
> a) @Veto is technically accurate, but not intuitive (and requires an
> understanding of class processing, which is not a user concern)
> b) @Exclude is intuitive when considered in the context of scanning but
> it's a bit unclear on a larger scale - 'what exactly is this class excluded
> from?' - the
> c) the annotation must be applicable to packages
>
> IMO, @Unmanaged describes best what happens to the class: it will *not*
> generate a managed bean automatically. It is very similar to @NoBean early
> suggested by Gerhard, but works on packages too, and it describes a quality
> of the annotated item, in the same way as @Transient stands for "not
> serialized".
>
> On 2011-12-27, at 5:43 PM, Marius Bogoevici wrote:
>
> > +1 @Veto
> >
> > -1 @Exclude
> >
> > @Veto has a very narrow meaning, and hints to
> ProcessAnnotatedType.veto(), which is precisely what happens to such
> annotated types. I have mixed feelings about @Exclude - I'd rather not
> introduce a new term, especially one that does not immediately make you
> think of CDI processing.
> >
> >
> > On 2011-12-26, at 6:41 PM, Gerhard Petracek wrote:
> >
> >> it looks like @Exclude is the alternative which would work for several
> of
> >> us.
> >> -> we have to choose between @Exclude and @Vote
> >>
> >> +1 for @Exclude
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2011/12/26 Jakob Korherr <jakob.korherr@gmail.com>
> >>
> >>> +1 to @Veto and @Exclude
> >>>
> >>> Also I agree with Pete's comments about the other suggestions.
> >>>
> >>> Regards,
> >>> Jakob
> >>>
> >>> 2011/12/24 Pete Muir <pmuir@redhat.com>:
> >>>> We chose @Veto originally, as it didn't deviate from the spec's veto()
> >>> method, so should be less of a learning curve. I don't like
> @Deactivate as
> >>> it makes it sound like you have to activate other beans. @Ignore is too
> >>> overloaded a term for me to be comfortable with it (@IgnoreWarnings). I
> >>> like @Exclude as it's closest to what makes most intuitive sense.
> >>>>
> >>>> On 24 Dec 2011, at 09:33, Christian Kaltepoth wrote:
> >>>>
> >>>>> Perhaps we should build a list of all suggestions and then start
a
> >>>>> vote which one to use.
> >>>>>
> >>>>> I think these are the names that were suggested:
> >>>>>
> >>>>> @Veto
> >>>>> @Skip
> >>>>> @Exclude
> >>>>> @Deactivate
> >>>>> @Ignore
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2011/12/23 Gerhard Petracek <gerhard.petracek@gmail.com>:
> >>>>>> hi arne,
> >>>>>>
> >>>>>> would be also ok for me -> +1
> >>>>>>
> >>>>>> regards,
> >>>>>> gerhard
> >>>>>>
> >>>>>>
> >>>>>> 2011/12/23 Arne Limburg <arne.limburg@openknowledge.de>
> >>>>>>
> >>>>>>> What about @Exclude?
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Arne
> >>>>>>>
> >>>>>>> -----Ursprüngliche Nachricht-----
> >>>>>>> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> >>>>>>> Gesendet: Freitag, 23. Dezember 2011 21:28
> >>>>>>> An: deltaspike-dev@incubator.apache.org
> >>>>>>> Betreff: Re: [DISCUSS] [DELTASPIKE-8] @Veto
> >>>>>>>
> >>>>>>> +0.5 for @Skip
> >>>>>>> as mentioned in the original thread @Veto is accurate from
a
> technical
> >>>>>>> perspective, but it sounds strange for users who aren't
aware of
> the
> >>>>>>> mechanism behind.
> >>>>>>>
> >>>>>>> if we are talking only about @Veto vs @Skip and not about
the other
> >>>>>>> alternatives: +1 for @Skip
> >>>>>>>
> >>>>>>> regards,
> >>>>>>> gerhard
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2011/12/23 Dan Allen <dan.j.allen@gmail.com>
> >>>>>>>
> >>>>>>>> Veto is rationally the most appropriate since it directly
> translates
> >>>>>>>> to calling ProcessAnnotatedType#veto()
> >>>>>>>>
> >>>>>>>> However, I'd like to offer one other alternative:
> >>>>>>>>
> >>>>>>>> @Skip
> >>>>>>>>
> >>>>>>>> While veto describes what the extension is doing internally,
skip
> is
> >>>>>>>> how the developer perceives the result of the action.
The class is
> >>>>>>>> "skipped over" during the scanning process. This is
similar to the
> >>>>>>>> suggestion @Ignore, and I think both would get the point
across
> >>> equally
> >>>>>>> well.
> >>>>>>>>
> >>>>>>>> -Dan
> >>>>>>>>
> >>>>>>>> p.s. Apologizes for dropping the rest of the thread.
I wasn't
> >>>>>>>> receiving messages when this thread started.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Dan Allen
> >>>>>>>> Principal Software Engineer, Red Hat | Author of Seam
in Action
> >>>>>>>> Registered Linux User #231597
> >>>>>>>>
> >>>>>>>> http://www.google.com/profiles/dan.j.allen#about
> >>>>>>>> http://mojavelinux.com
> >>>>>>>> http://mojavelinux.com/seaminaction
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Christian Kaltepoth
> >>>>> Blog: http://chkal.blogspot.com/
> >>>>> Twitter: http://twitter.com/chkal
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jakob Korherr
> >>>
> >>> blog: http://www.jakobk.com
> >>> twitter: http://twitter.com/jakobkorherr
> >>> work: http://www.irian.at
> >>>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message