eclipse-platform
DocumentProviderRegistry.getDocumentProvider(IEditorInput) should try to adapt the editor input
Currently one needs to implement an additional extension point to adapt an IEditorInput to an IDocumentProvider additionally org.eclipse.ui.texteditor.DocumentProviderRegistry.getDocumentProvider(IEditorInput) should use the Adapter framework as well for the provider.
An important thing to keep in mind is the multiplicity: what are the assumption if document is request for the same IEditorInput multiple times (IIRC it would create only 1 document per provider, but I'm not sure); there are risk of breaking some assumptions if we go just for adapter without clear note of what it does better/worse. If possible, the constraints should be explicited somewhere by the way.
IDocumentProvider already has a mean to "connect" multiple objects, what leads me to this is that the extension point used here actually do very similar than what the adapter pattern offers (e.g. walking down the chain of provided "types") but Adapters as the can be OSGI services are much more flexible than classical extension points (beside that the IEditorInput itself is already adaptable).
I'm not sure why this would require api changes?
IDocumentProvider already has a mean to "connect" multiple objects, what leads me to this is that the extension point used here actually do very similar than what the adapter pattern offers (e.g. walking down the chain of provided "types")
Yes, but there could be multiple IDocumentProvider(s) which could then return different objects for the same "connection" input. Also the document provider can be used to disconnect/dispose documents; and disposing docs is critical. How do you envision handling the lifecycle of a document through an adapter? What will be responsible of disconnecting/disposing it? Isn't there a risk it just stays in memory forever?
I'm not sure why this would require api changes?
I've added the tag because I think it requires at least clarification in the documentation of existing APIs to mention the feature and its impact/benefits/limitations.
Maybe I missed the point, but how is it differently from the current extension point DocumentProviderRegistry.getDocumentProvider(..) uses? I would assume the same handling that we do here will apply to objects getting through adapters would be apply there as well ...
OK, so the usage of adapter would be only internal to getDocumentProvider(...) ? If so, then I agree it's probably fine; my worries were more if you were willing to directly adapter IEditorInput to IDocument.