Less cumbersome, sure. But it also breaks the object-oriented contract. Imagine this situation: a third party develops a powerful node type (let's say: a virtual router) with many well-defined and polished operations on custom interfaces (with their own types), custom workflows for various advanced features, and even comes with custom ARIA-based tooling for real-time analysis and monitoring.
Someone can come along and create a node template based on this node type that changes the operation inputs. For this to work properly, that someone *should* also provide a new operation implementation that would deal with these different inputs. But, these inputs must be sent for this to work: so the custom workflows must also be changed, as well as the custom tooling. And if new tools come along from that that third party, they will not work. Object-oriented is cumbersome, sure. :) But that's also the design principle of TOSCA, and this is a case that breaks it. We either want our node types to have extensible contracts, or allow them to have breakable contracts. It doesn't make sense to me to be somewhere in between: strictness should be all the way. Finally, I don't understand this question: On Wed, Nov 22, 2017 at 7:21 AM, Avia Efrat <a...@cloudify.co> wrote: > By the way, do you see a way of not being able to derive the value of an > intrinsic function's 'result'? (I know it is not currently supported) >
