Community
Participate
Working Groups
This bugzilla is a sub task of Bug 456410 to define and use an alternate API for allInstances query.
More specifically, this is about all the cases where Sirius iterates on the whole eAllContents() of (part of) a model to locate the subset of elements which match some criterion (typically, all the instances of a given type). Note that there may be places where we do iterate on "eAllContents()" without an explicit call to EObject.eAllContents() (for example via helpers like AllContents, or using explicit recursion on eContents()). Instead, we want to: * define a higher-level API which provides this kind of service ("find me all the elements which match criterion C inside scope S") * provide a default implementation which uses the "dumb" but completely generic implementation * refactor all existing code which hard-codes the "dumb" strategy to use the service API instead * provide some way for Sirius it and client code to plug custom implementations of the service API for specific criterions and/or scopes An exemple of the kind of gains we expect: Sirius could provide custom implementations for its own resources (aird and odesign) that leverage its static knowledge of the structure of these resources. For example if we get a query for an instance of uml.Package, we can answer immediatly that there will be none in any aird of VSM, without iterating on their content.
Moving to 4.0 as we do not want to break APIs for 3.1.
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.
