[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Annotations vs Events and when should we extend them ?
|
Hi,
I've stayed away from @Lifecycle and moved to the more generic
@Invoke("blabla").
See my github fork for the implementation.
Please note that on the low-level what I'd like to have is:
a) possibility to mark a method to get invoked and the parameters to be
filled out from the DI engine
b) a more lightweight possibility beside having to invent annotations
I think using annotations is a good way when provider and consumer are
very tightly bound together which is the case when we look at lifecycle
handling. Using the event-system in this case doesn't feel good because
90% when you get invoked you are not interested in the information and
skip it.
I don't see finding the Keys one can use any harder than locating the
annotations.
Tom
Am 08.11.12 12:40, schrieb Wim Jongman:
> Hi,
>
>
> One rule can be that the annotation should be generic. For example, the
> @Execute, @PostConstruct, @PreDestroy (border line case) can be re-used
> by other frameworks where as @Focus replaces a IView API which is not so
> good IMHO. This opens the door to other similar annotations like
> @IsDirty @IsAboutToShow and stuff like that.
>
>>
>> I much more love us to have 1 annotation named @Lifecycle but allow it
>> to hold a meta value @Lifecycle("PROCESS_ADDITION"),
>
> The problem I see with the parameter annotations is that there is no
> documentation or code completion that tells the developer what can be
> used in certain cases. If you want to have it documented would it then
> not be better to do something like:
>
> @Lifecycle(preShutDown=true)
>
> Regards,
>
> Wim
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Nov 7, 2012 at 11:33 PM, Tom Schindl
> <tom.schindl@xxxxxxxxxxxxxxx <mailto:tom.schindl@xxxxxxxxxxxxxxx>> wrote:
>
> I started exploring this @Lifecycle stuff but made it now more generic
> by using an injection named @Invoke
>
> You can find my work at
> https://github.com/tomsontom/eclipse.platform.runtime
>
> Tom
>
> Am 07.11.12 21:44, schrieb Tom Schindl:
> > Hi,
> >
> > First of all I think annotation should be used with great care
> here are
> > the rules I'd set out for when to use them.
> >
> > * when we need to get return value e.g. to cancel something
> >
> > * if the information is very tightly scoped to the information
> provider
> > and many developers will make use it (performance!)
> >
> >
> > IMHO lifecycle is better done with annotations, instead of events and
> > the rest of the lifecycle is already annotation based.
> >
> > A problem i have with the current annotation based system is that
> it is
> > very static - we have to invent too many different annotation.
> >
> > I much more love us to have 1 annotation named @Lifecycle but allow it
> > to hold a meta value @Lifecycle("PROCESS_ADDITION"),
> > @Lifecycle("PRE_SHUTDOWN"), ... and we have another invoke on the
> > ContextInjectionFactory where we pass this meta value.
> >
> > Such a feature would be very welcome to implement
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=392903 which has to
> based
> > upon annotation because we need to have a return value, and using the
> > event system is simply to cumbersom because the event is fired for
> each
> > and every element and the receiver has to skip the processing in
> 95% of
> > the cases (once more performance!).
> >
> > Tom
> >
> > Am 07.11.12 20:12, schrieb Eric Moffatt:
> >>
> >> While looking at
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=376821I
> >> realized that we should have some general guidelines for use in
> similar
> >> situations...
> >>
> >> My general feeling is that we need to be strict(er) about annotations
> >> since I'm afraid that they'll get out of hand otherwise but I really
> >> don't have a particular metric in mind for deciding which
> technique we
> >> should use. In the case of the defect above the choice was made
> easier
> >> since it is clearly a UI Lifecycle event.
> >>
> >> Can anybody think of a 'rule' for deciding when we should use one
> versus
> >> the other ?
> >>
> >> Eric
> >>
> >>
> >> _______________________________________________
> >> e4-dev mailing list
> >> e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
> >> https://dev.eclipse.org/mailman/listinfo/e4-dev
> >>
> >
> >
>
>
> --
> B e s t S o l u t i o n . a t EDV Systemhaus GmbH
> ------------------------------------------------------------------------
> tom schindl geschäftsführer/CEO
> ------------------------------------------------------------------------
> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512
> 935833 <tel:%2B%2B43%20512%20935833>
> http://www.BestSolution.at phone ++43 512
> 935834 <tel:%2B%2B43%20512%20935834>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833
http://www.BestSolution.at phone ++43 512 935834
