|
| Re: Closure + ClosureAll operation [message #30397 is a reply to message #30360] |
Thu, 06 April 2006 16:36   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Stefan,
I don't know what version of the OCL parser you're currently using, but
today's M6 build will update it to implement the latest "available
specification" of the OCL 2.0 from the OMG.
The OCL 2.0 specification does not include closure() or closureAll()
operations in the standard library (perhaps OCL 1 did?).
In today's build I have implemented a closure() iterator; I don't know what
the first authors of the parser had intended closureAll() to mean. The new
implementation of closure() has the typical iterator form and recursively
applies the body expression to the results of applying it on the source
collection.
For example, you could specify the EClass.eAllSuperTypes property by:
package ecore context EClass
derive: eAllSuperTypes : Set(EClass) =
self->closure(e : EClass | e.eSuperTypes)
endpackage
(taking advantage of the fact that -> on a scalar coerces it to a set).
The transitive closure algorithm is tolerant of cycles and does not include
the elements of the source collection (in the case the implicit Set{self})
unless they are reached by recursion. So, to include self as well in the
above example, you would do:
self->closure(eSuperTypes)->including(self)
Cheers,
Christian
Stefan Haensgen wrote:
> Hi,
>
> I have question concerning the closure/closureAll operation. In
> AnyTypeImpl you can find this operations among oclIsKindOf and others,
> but in the EvaluationVistiorImpl's accept method it does not appear like
> the other operations.
> Is it planned to support this operation in the future and what is
> actually the semantic of it. Is it related to a transitive closure.
>
> Thanks
> Stefan
|
|
|
| Re: Closure + ClosureAll operation [message #30432 is a reply to message #30397] |
Thu, 06 April 2006 16:39 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Oops! Mixed up my derive: and def: syntax. The example constraint should
read:
package ecore context EClass::eAllSuperTypes : Set(EClass)
derive: self->closure(e : EClass | e.eSuperTypes)
endpackage
Christian
Christian W. Damus wrote:
>
> Hi, Stefan,
>
> I don't know what version of the OCL parser you're currently using, but
> today's M6 build will update it to implement the latest "available
> specification" of the OCL 2.0 from the OMG.
>
> The OCL 2.0 specification does not include closure() or closureAll()
> operations in the standard library (perhaps OCL 1 did?).
>
> In today's build I have implemented a closure() iterator; I don't know
> what
> the first authors of the parser had intended closureAll() to mean. The
> new implementation of closure() has the typical iterator form and
> recursively applies the body expression to the results of applying it on
> the source collection.
>
> For example, you could specify the EClass.eAllSuperTypes property by:
>
> package ecore context EClass
> derive: eAllSuperTypes : Set(EClass) =
> self->closure(e : EClass | e.eSuperTypes)
> endpackage
>
> (taking advantage of the fact that -> on a scalar coerces it to a set).
>
> The transitive closure algorithm is tolerant of cycles and does not
> include the elements of the source collection (in the case the implicit
> Set{self})
> unless they are reached by recursion. So, to include self as well in the
> above example, you would do:
>
> self->closure(eSuperTypes)->including(self)
>
> Cheers,
>
> Christian
>
> Stefan Haensgen wrote:
>
<snip>
|
|
|
| Re: Closure + ClosureAll operation [message #573639 is a reply to message #30360] |
Thu, 06 April 2006 16:36 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Stefan,
I don't know what version of the OCL parser you're currently using, but
today's M6 build will update it to implement the latest "available
specification" of the OCL 2.0 from the OMG.
The OCL 2.0 specification does not include closure() or closureAll()
operations in the standard library (perhaps OCL 1 did?).
In today's build I have implemented a closure() iterator; I don't know what
the first authors of the parser had intended closureAll() to mean. The new
implementation of closure() has the typical iterator form and recursively
applies the body expression to the results of applying it on the source
collection.
For example, you could specify the EClass.eAllSuperTypes property by:
package ecore context EClass
derive: eAllSuperTypes : Set(EClass) =
self->closure(e : EClass | e.eSuperTypes)
endpackage
(taking advantage of the fact that -> on a scalar coerces it to a set).
The transitive closure algorithm is tolerant of cycles and does not include
the elements of the source collection (in the case the implicit Set{self})
unless they are reached by recursion. So, to include self as well in the
above example, you would do:
self->closure(eSuperTypes)->including(self)
Cheers,
Christian
Stefan Haensgen wrote:
> Hi,
>
> I have question concerning the closure/closureAll operation. In
> AnyTypeImpl you can find this operations among oclIsKindOf and others,
> but in the EvaluationVistiorImpl's accept method it does not appear like
> the other operations.
> Is it planned to support this operation in the future and what is
> actually the semantic of it. Is it related to a transitive closure.
>
> Thanks
> Stefan
|
|
|
| Re: Closure + ClosureAll operation [message #573662 is a reply to message #30397] |
Thu, 06 April 2006 16:39 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Oops! Mixed up my derive: and def: syntax. The example constraint should
read:
package ecore context EClass::eAllSuperTypes : Set(EClass)
derive: self->closure(e : EClass | e.eSuperTypes)
endpackage
Christian
Christian W. Damus wrote:
>
> Hi, Stefan,
>
> I don't know what version of the OCL parser you're currently using, but
> today's M6 build will update it to implement the latest "available
> specification" of the OCL 2.0 from the OMG.
>
> The OCL 2.0 specification does not include closure() or closureAll()
> operations in the standard library (perhaps OCL 1 did?).
>
> In today's build I have implemented a closure() iterator; I don't know
> what
> the first authors of the parser had intended closureAll() to mean. The
> new implementation of closure() has the typical iterator form and
> recursively applies the body expression to the results of applying it on
> the source collection.
>
> For example, you could specify the EClass.eAllSuperTypes property by:
>
> package ecore context EClass
> derive: eAllSuperTypes : Set(EClass) =
> self->closure(e : EClass | e.eSuperTypes)
> endpackage
>
> (taking advantage of the fact that -> on a scalar coerces it to a set).
>
> The transitive closure algorithm is tolerant of cycles and does not
> include the elements of the source collection (in the case the implicit
> Set{self})
> unless they are reached by recursion. So, to include self as well in the
> above example, you would do:
>
> self->closure(eSuperTypes)->including(self)
>
> Cheers,
>
> Christian
>
> Stefan Haensgen wrote:
>
<snip>
|
|
|
Powered by
FUDForum. Page generated in 0.03493 seconds
] 
Search
Help
Register
Login
Home
