Community
Participate
Working Groups
As the DatabindingAdapter<T extends IPatternMatch> class contains no additional features, if compared to the AbstractDatabindingAdapter, merging of these classes should be considered. Also consider removing the template parameter from the DatabindingAdapter class, as none of the methods of this class benefit from this feature. Both of these are in the same package and the DatabindingAdapter has no other inheriting classes, the merger therefore should not face any direct issues. Naturally it should be discussed if these classes are used outside VIATRA and how much effort it requires to adapt to these potential changes.
Balázs, as an advanced user of the data binding API, what do you think, would such a merge cause issues with existing users of the API (considering, we add a rewrite rule in the migrator)?
I see no reason to distinguish the two Adapters. Also, I would like to propose a few simplifications: First of all, calling them Adapters is a bit misleading, as they've nothing in common with EMF adapters and have no listener semantics. They're basically property factories, which only need to be instantiated to call their non-static, otherwise stateless methods. I propose to use the same factory pattern as in databinding: a non-instantiable (final class with private constructor) class with static factory methods. proposed API: MatcherProperties.value(IPatternMatch match, String parameterName) As the match already has reference to the QuerySpecification, the parameterName can be validated programatically, and the appropriate ObservableDefinition can be calculated on-demand. It does not seem to be expensive to justify a pre-calculated map, as the property (being a reusable element) will potentially be instantiated once for each parameter.
Rectification: the property should not be instantiated using the match element. It should use the IQuerySpecification: IValueProperty property = MatcherProperties.value(querySpecification, parameterName) property.observe(realm, match)
Added related tickets to 1.2
Could you look at these? Have fun. :)
New Gerrit change created: https://git.eclipse.org/r/69522
Gerrit change https://git.eclipse.org/r/69522 was merged to [master]. Commit: http://git.eclipse.org/c/viatra/org.eclipse.viatra.git/commit/?id=499a21ab81d6db903833055c20d158b1b5357ea6
