tosca-interop message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [tosca-interop] Background question on working assumptions about TOSCA types.
- From: Matt Rutkowski <mrutkows@us.ibm.com>
- To: Thomas Spatzier <thomas.spatzier@de.ibm.com>
- Date: Fri, 7 Jun 2013 13:11:30 -0500
Hi Dale,
Excellent questions! I can always
count on you to take a step back and make sure we understand the model
we are working towards.
Thanks Thomas for responding. Everything
Thomas conveyed I wholeheartedly agree with. Clearly, no multiple
inheritance and raising the use of "capabilities" for matching
(abstract node types which can be bound to a choice of impls.) is a high
priority for me which will be a fundamental part of what I hope we discuss
over the next few weeks.
Also, I would note that many of the
thoughts (questions) Travis conveyed reflect upon this need to have TOSCA
be less rigid in its type matching and which include allowing for more
robust Boundary definitions (using constraints and abstract type matching
using rules/regex). These all are convergent topics in my mind and
over time (although coming from different angles) will come to see this
and enabled by the the same methods.
Cheers.
Kind regards,
Matt
From:
Thomas Spatzier <thomas.spatzier@de.ibm.com>
To:
"tosca-interop@lists.oasis-open.org"
<tosca-interop@lists.oasis-open.org>
Date:
06/07/2013 02:03 AM
Subject:
Re: [tosca-interop]
Background question on working assumptions about TOSCA types.
Sent by:
<tosca-interop@lists.oasis-open.org>
Hi Dale,
some inline comments from my perspective below ...
Regards,
Thomas
<tosca-interop@lists.oasis-open.org> wrote on 06.06.2013 20:16:17:
> From: Dale Moberg <dmoberg@axway.com>
> To: "tosca-interop@lists.oasis-open.org" <tosca-interop@lists.oasis-
> open.org>,
> Date: 06.06.2013 20:15
> Subject: [tosca-interop] Background question on working assumptions
> about TOSCA types.
> Sent by: <tosca-interop@lists.oasis-open.org>
>
> Hi,
>
> Last Monday someone brought up whether we should think about TOSCA
> types as something like JS prototypes or more like OO classes.
>
> This question made me realize that I did not know what we are/were/
> will be assuming about TOSCA types, but I hope it will be something
> simple and not involve us in something like the “Lambda cube” and
> “Rank-N polymorphism” and the all the distinctions of the
> programming-language, type theorists behind Coq, ML, F, Haskell and
the
like.
>
> Here is what I had been assuming we meant by TOSCA types:
>
> 1. types can have subtypes
> 2. there is inheritance by subtypes.
> 3. subtypes inherit from at most one supertype (no multiple
> inheritance, no diamond)
Agree on all 3.
>
> Some things unclear to me from our documentation so far:
>
> 1. can anything (method,variable,value,default,etc.) be overridden
> in a subtype?
I did look at the spec, but from what I recall from writing most of it
I
think that a subtype can override everything. In some cases, there are
constraints, though. For example, when a supertype defines a capability
of
type A with name "mycap", a subtype can only refine "mycap"
with a
capability of type B that derives from A.
> 2. if there are abstract types, how do we tell when a type can be
> the type of, for example, a given node template? (we have 3 levels
> now, is the first level abstract and the other two concrete enough
> to have instances?)
So in my mental model, a Node Template can always be of an abstract type.
You can only not directly instantiate it. A TOSCA container will have to
find a replacement for the abstract type at the latest during deployment.
That replacement must be a non-abstract type that derives from the abstract
type referenced by the Node Template.
>
> I reserve the right to ask a few more questions depending on what
> answers I hear!
>
> [Matt, I have not finished all your slides, and maybe the answers
> were implicit somewhere, but I wasn’t smart enough to extract them.]
>
> Bye
> Dale Moberg
>
>
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]