Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Closure + ClosureAll operation
Closure + ClosureAll operation [message #30360] Thu, 06 April 2006 16:18 Go to next message
Stefan  Hänsgen is currently offline Stefan HänsgenFriend
Messages: 3
Registered: July 2009
Junior Member
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 #30397 is a reply to message #30360] Thu, 06 April 2006 16:36 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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>
Previous Topic:Closure + ClosureAll operation
Next Topic:JET Editor
Goto Forum:
  


Current Time: Sun May 19 05:21:50 GMT 2024

Powered by FUDForum. Page generated in 0.04812 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top