Right now the [automatically generated] references look like parent(2).op('ipar_op').par.Par1
, which kinda breaks the workflow of exposing internal parameters to higher levels because they have to edited by hand to ipar.Op.Par1
, which is often the desired outcome.
1 Like
(Edited for clarity)
To add to this, in my POV, the desired priority for generating automatic references when a parameter is being dropped onto another is as follows:
par.owner
is an internal OP defined in a parent OP (the closest parent in the hierarchy ‘wins’ in case of a conflict), create the reference usingipar.op_name.Par1
par.owner
exists as a parent shortcut (same conflict resolution criteria), create the reference usingparent.op_name.par.Par1
.par.owner
is globally defined, create the reference usingop.op_name.par.Par1
.par.owner
does not satisfy the above, create a reference usingop()
and / orparent()
(parent(5).op('op_name').par.Par1
)
This comes from a place in which refactoring your network is a common occurrence while building a solution, but there are rough boundaries you establish using ipars, parent shortcuts and global shortcuts, allowing some mobility without breaking references.
There’s probably space for disagreement, in which case the priority could be configured somewhere, either at a project level or at a global level.
Cheers.