Community
Participate
Working Groups
Cache mechanism was part of the core plugin and has been moved in resource loading plugin. It would be better the have a single plugin for that, to avoid inconsistent dependencies with resource loading
-> create plugin org.eclipse.papyrus.cache -> update references to the cache -> update releng and feature
What exactly is the purpose of this cache ? What kind of Object does it cache ? Who are the clients needing to require such object and when ? Normally, a cache mechanism should be transparent to its clients: a client should not be aware that the objects it require are cached. This doesn't seem to be the case in this implementation. If a client need to retrieve some kind of Objects, it should do it through a well defined API dedicated to this particular service, which should be domain oriented. The API should reflect the purpose of its service, not the fact that objects are cached. Later, the API implementation can decide to use a cache, but this should be transparent to the client. I propose to use such approach (a domain oriented API) rather than let the cache mechanism appear to client.
+1. Editors of Papyrus do not have to be dependant on any of these transversal services.
We talked about this point with Cedric at the phone I just added a service to get objects of specified type, using the cache in a transparent way: ModelSetQuery.getObjectsOfType If you agree with this name, I will move it in the core, in a package query to hide cache mechanism
+1
Cédric: Do you agree too with the names ? Then I will move it in the core.
I agree with the class name, but not the package name and impl.* names :-). Proposed names: - package: org.eclipse.papyrus.core.modelsetquery - impl.name: replace TypeCache by ModelSetQuery Also, the impl package should not be visible from outside of the plugin.
I agree with the names. About the package visibility, I hid it but you sometimes need it to manage the cache (add some objects into). For example we use it in org.eclipse.papyrus.resourceloading.umlprofile plugin. We could think about visible helpers/services to manage the cache with an interface next. Then, we will hide the impl package.
