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 <[email protected]>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
> >> [email protected]
> >> 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
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
