John, I've been wondering about the Logger myself but from a slightly different POV. I don't like the idea that it's a *class*, meaning that nobody can change it without breaking existing users. Wouldn't it be best of all services were interfaces ? I think that this is true for our other services but haven't looked deeply.
Eric From: John Arthorne/Ottawa/IBM@IBMCA To: E4 Project developer mailing list <[email protected]> Date: 03/05/2013 04:50 PM Subject: Re: [e4-dev] E4 Formal API Part 2: UI Model Sent by: [email protected] 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
