[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Overload resolution and dynamic dispatch patch
|
Ed,
On 5/7/2012 1:24 PM, Ed Willink wrote:
Hi Axel
I think you're confusing two different issues.
a) impact for unloaded Resources
b) impact through polymorphic calls
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.
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 perspective
knows 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?
Best,
-- Axel
Regards
Ed
On 07/05/2012 10:55, Axel Uhl wrote:
We may consider adjusting the impact analyzer by granting it access to
the dynamic dispatch cache. It may, however, lead to a situation where
an operation hasn't been evaluated in a given environment yet, hence
no cache entry is present for the operation, and hence the look up
would provide the IA with too few operation bodies to analyze.
I claim that generally, without having evaluated all expressions on
all objects, ensuring that all relevant operation bodies have been
evaluated at least once, no EMF-based approach can determine a change
impact because expressions affected by the change may simply not be
known by the environment.
A cleaner, probably not entirely satisfying approach may involve
equipping the IA with a set of EPackage objects which define the
"universe" of metamodels to be considered by the IA. The IA could
then, at some start-up cost, determine the operation bodies to be
considered.
Opinions?
-- Axel
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
