|Re: [mdt-ocl.dev] Overload resolution and dynamic dispatch patch|
a) unloaded Resources In your earlier example with resource Y (unloaded) so that propagation of 42 through resource X failed to impact: Using my dependency analysis perspective, if the Y resource is not loaded, I don't analyze it, I don't detect any dependencies, so I don't install any listeners/notifiers to cause the Y resource elements to react to changes. So I agree that it doesn't work. It's nothing to do with EMF-based; it's just common sense.not so common sense after all if a reference path leads through Y back to X. Which resources from a repository an editor loads into a ResourceSet is fairly random. JDT wouldn't be the same if errors in Java resources not currently open in an editor remained undetected until the resource is loaded.
Exactly. JDT knows how to open all files, and in order to report errors it either loads everything or exploits some sort of memento of previous results.
It seems to be mandatory to load all resources for which any form of analysis is to be performed. (It may be that they are unloaded retaining only a memento, but they must be loaded to create the memento.)
Consider a doctor's patient list and the impact of a policy change to invite all patients over 50 rather than over 60 to have a free flu vaccination for the winter. The derived property of the number of required injections can only be determined by examining each patients records. If a patient's record is not loaded into the system/looked at by a human, the accurate answer cannot be determined. It seems unreasonable to expect to have impact or dependencies for unloaded resources. b) polymorphic calls It seems that your traceback does not use the source object and so needs to consider all possible operations. This seems inefficient and may lead to fat notifications that can be filtered. The dependency perspectiveknows the source object and so need only consider the relevant operation.I don't understand your "dependency perspective." Maybe you can explain using the example I gave earlier?
For the derived property context X::derivedProperty : Integer = self.m().i on y1:Y, which is loaded so its dependencies are analyzed. - it is a Y, so Y::m() which is self.b.a so depends on -- the object identity at self.b, which is currently a B -- the object value at self.b, which is b.a, so depends on --- the object identity at self.b.a, which is currently an A --- the object value at self.b.a which is i, so depends on [---- the object identity i is not relevant since it is a data type] ---- the datatype value iEach of the dependencies needs a direct or transitive notifier chain to cause the change to propagate and in the case of identity changes, the notifier chain to be adjusted.
Back to the top