I'm using the Adapter/EclipseAdapter — no need to implement. The default implementation (EclipseAdapter) saves a lot of boilerplate since the IAdapterManager doesn't do an IAdaptable check. I personally can't think of anything else to add to its interface.
Re: Logger: agreed. The world doesn't need yet another logger interface. I wouldn't say IContributionFactory is ready as it doesn't have a story for extension points. Brian. On 5-Mar-2013, at 4:50 PM, John Arthorne wrote: > Eric Moffatt wrote on 03/05/2013 04:13:56 PM: > > Tomorrow I expect to have something on the Services; this is an area > > that I'll likely need input on since I only use the EModelService > > and EPartService. Tom, we're not going to declare the various > > presentation / rendering API now correct ? > > FWIW, I scanned through the "core" services in org.eclipse.e4.core.services > today. From what I can see, only IEventBroker is truly fleshed out and ready > to be treated as API. Logger is probably used enough at this point that we'll > need to keep it, although if I could do things over I'd pick the heavily used > SLF4J Logger API for better interop with existing code. Many of the other > services are used internally but I'm not sure we have proved they are > valuable abstractions or just incomplete replacements for existing 3.x API. > If any consumers are implementing their own IContributionFactory, Adapter, > StatusReporter, or TranslationService I would be curious to know about them. > If there are no strong use cases for making them API I suggest just leaving > them as internal/provisional for this release. > > John_______________________________________________ > 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
