relational-rags issueshttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues2021-02-03T09:33:21+01:00https://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/30Behaviour of treeCopy2021-02-03T09:33:21+01:00Johannes MeyBehaviour of treeCopyWhen copying a tree with relations, these relations still point in the old tree. This may be desired in some cases, but not in all (e.g., when a copy of an entire AST should be done).
There should be a concept of how to handle this.When copying a tree with relations, these relations still point in the old tree. This may be desired in some cases, but not in all (e.g., when a copy of an entire AST should be done).
There should be a concept of how to handle this.Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/22Interfaces or Multiple Types as Relation Endpoints2020-01-11T23:27:22+01:00Johannes MeyInterfaces or Multiple Types as Relation Endpoints
> :warning: this issue is still work in progress!
In some cases, a relation endpoint may not be one type, but a collection of types with a common interface. This is currently not possible, since interfaces are not defined in the gramma...
> :warning: this issue is still work in progress!
In some cases, a relation endpoint may not be one type, but a collection of types with a common interface. This is currently not possible, since interfaces are not defined in the grammar but in aspects.
This is mainly because the support for interfaces is part of the AOP-features not directly related to the grammar, so there is no support to add ast children to interfaces.
### Occurrence
Interfaces could be used in two places:
1. A nonterminal type implements an interface.
2. A nonterminal has a child with the type of an interface.
**Proposed Design Decision**: Only support variant 1. Variant 2 would probably require changes to JastAdd itself, while the first variant can be compiled down to plain JastAdd grammar and inter-type specifications.
## Lightweight: Union Types
- anonymous syntax proposal:
- `rel {TypeA,TypeB}.monitors* <-> {TypeB,TypeC}.monitoredBy*` or `rel (TypeA | TypeB).monitors* <-> (TypeB | TypeC).monitoredBy*`
- would generate interface like `UnionTypeATypeB` and `UnionTypeBTypeC`
- named syntax proposal:
- `interface Monitor;`, `interface Monitored;`
- `TypeA implements Monitor;`, `TypeB implements Monitor;`, `TypeB implements Monitored;`, `TypeC implements Monitored;`
- `rel Monitor.monitors* <-> Monitored.monitoredBy*`
- generated code:
- interface does only contains two methods for each type that implements it: `abstract boolean isTypeX();` and `abstract TypeX asTypeX();`
- maybe default implementations of Java could be used in the generated interface to reduce code length
- the correct implementation of these methods must be added to all implementing types
- discussion:
- :heavy_plus_sign: lightweight, not much implementation required
- :heavy_minus_sign: since the interface contains no other methods, the "cast" methods (or actual casts) are always required when navigating them
- cannot simply be used to in situations where Java interfaces were used
## Heavyweight: "Interfaces Types"
### Syntax
An interface declaration has the same structure as a type declaration with the following differences:
- It has exactly one modifier, `interface`.
- That means that it must not have a modifier `abstract`; the abstract modifier indicates that the type can not be instantiated, which is always true for an interface by definition.
- It may contain supertypes, but these supertypes may only be interfaces as well.
- supertypes are a comma-separated list in the place that previously contained one superclass
- This entails separate inheritance hierarchies for interfaces and types; mixing them would break the "natural" mapping to Java concepts.
Types can implement zero or more interfaces:
- (classic) types may contain supertypes are a comma-separated list in the place that previously contained one superclass
- only one of the supertypes can be a class, the others must be interfaces
Examples:
```
interface Named ::= <Name>;
interface Typed ::= ;
interface ElementContainer ::= Element*;
interface NamedElementContainer : ElementContainer,Named ::= ;
abstract ModelElement : Named ::= ;
Class : ModelElement,NamedElementContainer,Typed ::= /* children */ ;
```Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/3treeCopy and intrinsic references2020-01-10T14:10:29+01:00Johannes MeytreeCopy and intrinsic referencesUsually, `treeCopy()` is used to copy subtrees. The copying process copies terminal values directly, and, since intrinsic references are treated as terminal values, it also copies those directly.
There are two cases to consider:
* the i...Usually, `treeCopy()` is used to copy subtrees. The copying process copies terminal values directly, and, since intrinsic references are treated as terminal values, it also copies those directly.
There are two cases to consider:
* the intrinsic reference points outside of the copied fragment. In this case, the value of the intrinsic reference can be copied.
* the intrinsic reference points to a non-terminal in the subtree to be copied. In this case, the value of the reference should probably point to the copy of the old target.
Proposed change: treeCopy() has to be modified for all nonterminal types containing intrinsic references.Johannes MeyJohannes Mey