Community
Participate
Working Groups
Make the analysis of property use in QVTi mappings reusable, by separating it into a separate Class or set of static methods. Perhaps providing methods with signatures: - Map<Domain, List<Property>> getAccesedProperties(Mapping m) - Map<Domain, List<Property>> getSettedProperties(Mapping m) The first to the the properties accessed by statements in the mapping, the latter for properties being set. I think using Property is better than PropertyDatum, as the latter belongs to the Dependecy graph metamodel, and at least in my case I am not using it and hence would peffer not having a dependency to it. Also, using the PropertyDatums seems to imply that the dependency graph is aleady created. I would imagine that the QVTpToQVTg would used the proposed Class/API as part of its operation.
(In reply to Horacio Hoyos from comment #0) > I think using Property is better than PropertyDatum PropertyDatum is not the greatest of names but Property won't work. For endogeneous transformations, the in-Property and out-Property may be the same Property but have distinct analyses. ---- Note that ClassDatum now has a TypedModel feature. Perhaps the DomainUsageAnalysis/TransformationAnalysis can be expanded/generalized so that we have DomainUsage PropertyUsage ClassUsage ---- Note also that the QVTc/QVTu/QVTm/QVTp are all declarative languages (no imperative capabilites such as Mapping calls). Only QVTi is different with imperative constructs. The Java QVTm2QVTp rewrite generates a CoreModel. The DomainAnalysis and a couple of consumers are QVTc/QVTm agnostic once they are coded to use the shared AbstractMapping rather than the specific derived Mapping.
From the mailing list: "In general, using PropertyDatum seems to imply that the Dependency Graph has already been created. What I propose is an API/Class that could be use in alternative creation of "dependency graphs" or equivalent. " It is not at all clear what you want. I assume by the dependency graph you mean the discovery of producers and consumers for each mapping input/output. Any analysis prior to this discovery could be hideously general. Analysis after this is already there in the new scheduler to populate the new checked and enforced dependencies while synthesizing the QVTi. This is pessimistic where there are multiple property accesses such as "name" to distinct derived types. I'm inclined to add an Annotation to a NavigationCallExp and an Annotation/Property to a PropertyAssignment so that each access is annotated individually and precisely.
(In reply to Ed Willink from comment #2) > Any analysis prior to this discovery could be hideously general. > > Analysis after this is already there in the new scheduler to populate the > new checked and enforced dependencies while synthesizing the QVTi. My scheduling research has diverged a lot from the current "new scheduler" (refering to the scheduler used in the master QVTd MTC). I would prefer, if possbile, not to have to run the master QVTpToQVTg to get the property dependency information and then run my own QVTpToXXX (where XXX is a dependency graph of another natrure or similar). So my request is, if possible, that the methods/classes that analyse and individual mapping (or it could be assignments and predicates) and find the propertyes accessed/set are designed so they can be resued by others.
(In reply to Ed Willink from comment #1) > Perhaps the DomainUsageAnalysis/TransformationAnalysis can be > expanded/generalized so that we have > > DomainUsage > PropertyUsage > ClassUsage I find the DomainUsageAnalysis of little use, at least for my case, because for each element you get the list of TypedModels/Domains in which the element is accesed, but you can not know the specifc mapping in which it was used.
I think that with a minor refactoring we can partially help here. We currently have a ClassRelationship, which is not more than a meta-model information based cache to get useful information from Pivot classes (e.g. get all super classes). As of Bug 485140, QVTp2QVTg also holds some caches between Mappings and OperationCallExps, NavigationCallExps (property reads) and PropertyAssignments (property writes) Therefore I could decouple the code so that QVTp2QVTg uses a MappingRelationships so that the useful caches reside in their own class. The DomainAnalysis is independently used in QVTp2QVTg, and I presume you are not interested in that. With that MappingsRelationship class and additional code, you can get the information that you need, and it's still useful in its own. Horacio is this OK for you ? P.S: We might want to call the new java class with a more general/broader name, in case we want to add more caches not strictly related to Mappings. Possible names are welcome. Regards, Adolfo.
(In reply to Adolfo Sanchez-Barbudo Herrera from comment #5) > The DomainAnalysis is independently used in QVTp2QVTg, and I presume you are > not interested in that. The DomainAnalysis is probably pursuing the correct algorithm, it's just caching the 'wrong' results. Since the Visitor hierarchy is currently used for language extension, inheritance cannot also be used for result caching, so I suggest a new e.g. AnalysisResult class that can have DomainAnalysisResult or MappingAnalysisResult derived classes for the distinct result precisions. There may also be a need for distinct algorithms. When I designed the DomainAnalysis I was considering the dataflow directly associated with an AST element; so for a PropertyAssignment to a 'name' the DataType is String and the domain is $primitive$. However for partitioning it is necessary to know e.g. if any of the partial expressions of a PropertyAssignment is in the left domain; a deep rather than shallow domain analysis. The intent of these algorithms needs to be captured more accurately in comments.
