@PreDestroy is not borderline
On Thu, Nov 8, 2012 at 12:40 PM, Wim Jongman <[email protected]> wrote: > 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
