To discuss: disable automatic resolution of requirements

[goldhoorn]

This is a point for discussion.

I had the strong feeling that fore more and more complex system requirements got ambigious in any case. Therefore most of the requirements have to specified with .use in any case. The Automatic resolution confuses at some points because a non-specified composition is choosen automatically, example:

define "something", A.def(foo => bar)

class compo << Syskit::Composition
    add A, :as => bla
end

Then without forwarding, A is choosen automatically without the foo => bar specification. This is oftern (in more system confusing).

A generic resolution could still be done by

 using A => A.def(foo => bar) 

in the profile.

I recomment therefore to get completly rid of automatic instance requirements selection. This would solve #34 and #23 too.

[doudou]

Your example sucks. I am sorry to use this very strong wording, but I really don't see any other way. I'm ignoring the minor syntax errors, but A.def does not exist (did you mean A.use ?). foo and bar do not exist (what do they mean to select).

Moreover, this is IMO unrelated to #23 and #34

[goldhoorn]

To correct my example

define "something", A.use(foo => some_requirement_that_makes_this_non_ambigious)

class A < Syskit ::Composition
   add Something_That_needs_to_be_specified_otherwise_its_ambigious, :as => 'foo'
end

class Compo < Syskit::Composition
    add A, :as => bla
end

If then Compo get's added because of something, A.foo_child get's ambigious. If you have a larger setup by encapsuling compositions the error got sometimes really confusing because the unspecified Composition (instead of something_def) is choosen automatically.

Why i mention the relation to #23 and #34 is that the automatic selection of InstanceRequirements causes both problems. If no automatic lookup would be done both issues would dissappear from my point of view.

[doudou]

If then Compo get's added because of something, A.foo_child get's ambigious. If you have a larger setup by encapsuling compositions the error got sometimes really confusing because the unspecified Composition (instead of something_def) is choosen automatically.

Isn't that the real problem then ? That the automatic selection does not take into account something_def ? At least it looks like it really is what you find confusing, not so much the automatic selection.

23 is a general. In your particular case, you needed it because of automatic selection, but the automatic selection is not the source of the issue

34 has IMO no relationship with it. Please explain why you think so (I've done some explanations in the #34 discussion thread, you should have a look there).

[doudou]

OK, to summarize @goldhoorn's point

• automatic selection is too magic, and it is harmful for bigger systems
• it is related to other buts (#23 and #34)

And mine:

• I believe that #23 and #34 are unrelated. #23 is indeed needed if you want to remove an optional child when the automatic selection kicks in. But I also believe that it is an important ability in the context of profile reuse. #34 is IMO unrelated.
• I do realize that I never really given a position on the "removing automatic selection" part of the discussion. It would go towards the goal of "less magic in syskit", which is an overall goal we had so far. My issue with it is that it would make simple systems a lot more cumbersome to use, thus raising the barrier to entry in syskit.