Never mind, I already got an answer from the spec =) On Wed, Nov 22, 2017 at 6:29 PM, Tal Liron <[email protected]> wrote:
> 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 <[email protected]> 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) > > >
