Bug 456410 - Define and use alternate APIs for high-level model queries that can be extended/customized when appropriate
Summary: Define and use alternate APIs for high-level model queries that can be extend...
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 2.0.0   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Project inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on: 466590 466591
Blocks:
  Show dependency tree
 
Reported: 2014-12-31 05:14 EST by Pierre-Charles David CLA
Modified: 2016-04-11 08:04 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre-Charles David CLA 2014-12-31 05:14:25 EST
There are some common patterns for walking/searching inside EMF models that are repeated very often in Sirius, and which are implemented each time using the core EMF mechanisms. Beyond the code duplication, doing it this ways prevents any context-dependent optimizations.

For example, we often directly use eAllContents() or equivalent to search for elements of some kind. We could provide a higher-level service for this, which could be smarter than the "dumb" implementation (for example by not looking inside elements which can be proven statically to not contain the kind of elements we look for), and more importantly we could allow client code to provide custom implementations that are optimized for their context.

Examples of services/operations that could be abstracted:
* looking inside a model for elements of a given type. The "dumb and costly" way is a plain eAllcontenst() with calls to EClassifier.instanceOf().
* searching for inverse references towards a given element. The "dumb and costly" way is to maintain a complete inverse cross referencer.
* given a resource, knowing which other resources it references or that references it (i.e. the resource-level incoming and outgoing references). The "dumb and costly" is to load/resolve all the concerned resources and do a complete walk of all of them.
Comment 1 Pierre-Charles David CLA 2014-12-31 05:55:21 EST
The APIs and basic/generic implementations should probably live in org.eclipse.sirius.ext.emf, and be independant of Sirius.

The Session should provide access to implementations of these appropriate in its context. By default it would be either the versions from org.eclipse.sirius.ext.emf or customized/extended versions adapted to the context of a Sirius session. Some extension mechanism must be provided so that clients can customize the implementations or provide alternate implementations for individual sessions.
Comment 2 Eclipse Genie CLA 2015-04-16 11:18:42 EDT
New Gerrit change created: https://git.eclipse.org/r/45945
Comment 3 Eclipse Genie CLA 2015-05-04 03:16:30 EDT
New Gerrit change created: https://git.eclipse.org/r/47005
Comment 5 Eclipse Genie CLA 2015-05-13 09:55:29 EDT
New Gerrit change created: https://git.eclipse.org/r/47845
Comment 6 Eclipse Genie CLA 2015-05-13 10:02:16 EDT
New Gerrit change created: https://git.eclipse.org/r/47847
Comment 8 Pierre-Charles David CLA 2015-06-23 10:29:18 EDT
Moving to 4.0, we do not want to break APIs for 3.1.
Comment 9 Pierre-Charles David CLA 2015-12-15 04:11:51 EST
Moving out of the 4.0 scope for now, along with all the other issues which were there "by default". This does not mean some of these will not be re-integrated at some point, but for now these issues are not part of the roadmap for 4.0.

If you feel strongly about this removal from 4.0 and/or are ready to sponsor the corresponding work, feel free to comment.