incubator-deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] [DELTASPIKE-8] @Veto
Date Wed, 28 Dec 2011 07:39:05 GMT
hmm, what about @Typed() ? :)

I think that was the exact reason why we intentionally left it out originally ;)

LieGrue,
strub



----- Original Message -----
> From: Gerhard Petracek <gerhard.petracek@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Wednesday, December 28, 2011 1:50 AM
> Subject: Re: [DISCUSS] [DELTASPIKE-8] @Veto
> 
> hi john,
> 
> the basic contract is still the same (the implementation will be the
> implementation which is currently available in seam3) - just the name is
> more expressive.
> 
> regards,
> gerhard
> 
> 
> 
> 2011/12/28 John D. Ament <john.d.ament@gmail.com>
> 
>>  Unmanaged sounds a little confusing.  this simply represents the default
>>  implementation of the bean, correct?  so an app developer can create a
>>  manual producer... right?
>> 
>>  On Tue, Dec 27, 2011 at 7:24 PM, Gerhard Petracek <
>>  gerhard.petracek@gmail.com> wrote:
>> 
>>  > +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
View raw message