That sounds good. If the factory methods return instances of IEclipseContextControl (or IEclipseContextInternals?) then that interface is an obvious location where one can look up more information. There would be no casting, and no conditional invocation of methods. If other clients only see IEclipseContext then dispose() etc. are also hidden.On Oct 20, 2009, at 16:03 , Oleg Besedin wrote:
I think this is a good point and something that we should look into. As a background, this was done, believe it or not, in the name of simplicity.
There are two roles when it comes to contexts: the contexts I created, and the contexts I got from somewhere else.
For the "contexts I created", it makes sense to be able to control the life cycle. However, for the contexts passed to the parts, I'd like to: a) make them as simple as possible, without any strange methods; and b) I would be unhappy if somebody actually disposed of my context.
From a quick glance it seems that we can achieve this separation by having an extra interface IEclipseContextControl (inherits from IEclipseContext) with dispose and other "strange" methods to be returned by context factories. I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=292766 for this.
Sincerely,
Oleg Besedin
Commenting out of complete ignorance regarding the actual problem,
but: I've never liked this kind of pattern, because it is hard to
discover and easy to forget.
Is there a better way of handling life cycle stages? I would expect
this kind of method to be always there, possibly with empty
implementations.
Greetings,
Axel
On Oct 20, 2009, at 14:39 , Paul Webster wrote:
> If code creates a creates a context with EclipseContextFactory then
> they should dispose it when they're done with it. i.e. in our
> model/renderer code we have to create and dispose the context. We use
> the pattern with IDisposable (as you found :-)
>
> if (context implements IDisposable) {
> ((IDisposable)context).dispose();
> }
>
> PW
>
> --
> Paul Webster
> Hi floor. Make me a sammich! - GIR
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
--
Axel.Rauschmayer@xxxxxxxxxx
http://www.pst.ifi.lmu.de/~rauschma/
_______________________________________________
e4-dev mailing list
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
|
