Github user ahgittin commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/987#issuecomment-151464184
Very helpful comments @neykov . Have done most of them; still need to:
* Think about `SelfType` generics
* Check double dispatch
I saw the relationships as rather more standardized than config keys -- for
instance `in_location` or `has_policy` or `has_child` or `has_network` -- and
providing mixin behaviour where the target applies behavior. Thus independent
of specific entities, for the most part; though new ones can be added I think
we should aim to reuse quite a bit more than config keys.
I have been in two minds about whether relationships might in time have
more behaviour and configuration. In TOSCA for instance relationships can have
both. An example could be machine entities with networks; the relationship
(link) instance could specify which network(s) might be preferred for different
entities, without needing to make some networks globally preferred or introduce
proxy network instances. Not terribly compelling -- the use cases are still
unclear -- but I think we should be open to this possibility in the future. So
I'm going to do a third minor change to leave room for this:
* Change existing references to `Relationship` to `RelationshipType`, as in
`relations().getRelationshipTypes()`. This would allow us in the future to add
`Relationship` as a `BrooklynObject` type where we could have instances
supporting configuration, and we could do `relations().getRelationships()` to
return those instances so that callers could filter, but without committing to
that now.
WDYT?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
