Why does ClusteringBuilderState.writeNewResourceDescriptions copies computed IResourceDescription ? [message #1220512] |
Thu, 12 December 2013 09:30 |
Flo Plateau Messages: 16 Registered: December 2013 |
Junior Member |
|
|
Hi,
I'm wondering why ClusteringBuilderState.writeNewResourceDescriptions makes a copy of the resource description it computes to perform the linking:
subMonitor.subTask("Writing new resource description for " + uri.lastSegment() + " (" + index++ + " of " + n + ")"); // TODO: NLS
final IResourceDescription.Manager manager = getResourceDescriptionManager(uri);
if (manager != null) {
// We don't care here about links, we really just want the exported objects so that we can link in the
// next phase.
final IResourceDescription description = manager.getResourceDescription(resource);
final IResourceDescription copiedDescription = new CopiedResourceDescription(description);
// We also don't care what kind of Delta we get here; it's just a temporary transport vehicle. That interface
// could do with some clean-up, too, because all we actually want to do is register the new resource
// description, not the delta.
newState.register(new DefaultResourceDescriptionDelta(oldState.getResourceDescription(uri), copiedDescription));
buildData.queueURI(uri);
}
As my IEObjectDescriptions contain lazy fields, this copy disturbs me (actually, it causes a failure), thus if it is done only for optimization purpose, I would like to avoid it.
Thanks in advance,
Florence
|
|
|
|
|
|
|
Re: Why does ClusteringBuilderState.writeNewResourceDescriptions copies computed IResourceDescriptio [message #1220774 is a reply to message #1220740] |
Fri, 13 December 2013 14:14 |
Flo Plateau Messages: 16 Registered: December 2013 |
Junior Member |
|
|
My DSL contains functions and types. As my DSL allows to define several functions with the same name as soon as their parameters types are different, when I resolve a link to a function I have to know its parameters types, in order to choose the right target function (depending on the effective arguments types).
That is why I store the parameters types in the user data of the functions IEObjectDescriptions. I cannot use the text of the type, available in the node model, because my DSL allows to define alias types, and I have to store the normalized version of the parameters types. To this end, I have to resolve the type references to see in the type declaration if it is an alias to another type. That is why the user data of my functions IEObjectDescriptions is stored in a lazy field (the IEObjectDescriptions are computed to prepare the link phase, it should not trigger it).
All this worked fine until I started to use a Control Version System to manage the code I write with my DSL. When I update the code (and thus modify it outside eclipse), the next build raises a ClassCastException because of some encoded xtext links that seem to be outdated w.r.t. the new version of the files. This exception occurs during the computation of the lazy user data of my functions, itself triggered by the IEObjectDescriptions copy performed in ClusteringBuilderState.writeNewResourceDescriptions. Everything seems to work fine if I remove the call to new CopiedResourceDescription(description). But as I don't understand the role of this copy, I'm afraid to be missing something. That's why I asked some explanations about this copy.
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04290 seconds