[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Overload resolution and dynamic dispatch patch
|
Ok, understood. This conflicts with the way the current IA approach
works. It is geared towards non-loaded resources and large, scalable
repositories. The design assumes that it's impractical to load all
relevant resources into memory, analyze and then memorize all
dependencies for all OCL expressions for all context elements. Instead,
it is analyzing the expression structure up-front, then deriving the
change listeners which obviously need to be registered only on objects
loaded into memory because only for those changes can be detected at
all. Once a change occurs, the change is analyzed by traversing the
element graph "backwards" using the expression structure. This also
works for even the largest repositories because the memory required for
backwards traversal doesn't grow with repository size.
It would be good if we knew which classes were generally available in
the scope of a ResourceSet so as to scan their operations during
backwards traversal ("traceback"). For the "traceback" approach this
would consider all operations known/loaded at that time. The
NavigationStep approach which is pre-computing the traceback paths would
not work this way because it wouldn't know operations loaded through
metamodels that become available after the IA has pre-computed the
navigation steps.
What would be a good way to scan all existing operations and be notified
when new subclasses with redefinitions / overrides become available?
Wasn't there an open EMF bug requesting a notification mechanism for
EPackage loads?
Best,
-- Axel
On 5/7/2012 9:06 PM, Ed Willink wrote:
Hi
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 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?
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 i
Each 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.
Regards
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
