[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.modeling.mdt.ocl] Re: OCL closures implementation
Hi, Ed,

Good point about the helper operation:  I hadn't considered that the formal definition of the closure() iterator could include additional operations.  Of course, it can!

I can think of a few arguments against the object iterator construct:

  - it would be the first instance of its kind, a new language construct.
    It probably needs to be able to show that it cannot be implemented
    by any other mechanism (such as collection iterator) to justify that

  - the "." operator makes "closure" look like a model operation.  An "ocl"
    prefix could help, but then it still looks like an operation, not an
    iterator

  - I'm not sure that it's a good idea to always include the initial object
    in the closure.  It's easy enough to extend the _expression_ to add it
    (e.g., "root->closure(kids)->including(root)" ) than it is to extend the
    _expression_ to remove it.  In the latter case, e.g.,
    "root->closure(kids)->excluding(root)" there's no way to know that
    root shouldn't be in the closure because it was reached via a cycle

Note that the arrow operator coerces scalar values to singleton sets, so you can do

   root->closure(kids)

to get the closure of the kids association and, if necessary,

   root->closure(kids)->including(kids)

to ensure that the result has the root, also.  If this is a very common case, it may justify an additional iterator, say

   root->withClosure(kids)

that includes the starting collection.

Just $0.02 from a still-interested-though-somewhat-remote party  :-)

Cheers,

Christian


On Sun, 2009-08-09 at 22:20 +0100, Ed Willink wrote: 
Hi Neil, Christian, Nicolas

I stumbled over the experimental closure() implementation a few days 
ago. It seems interesting. I see this has been raised as OMG Issue 
13944. The RTF committee is so busy that if we want to get this in
OCL 2.3 there are better chances if the submission is formatted ready
for inclusion in the RTF report.

I think the recursive specification difficulty can be easily cured by 
using infinite recursion of a helper function and a set that makes 
further recursion redundant.

After trying to use the closure iterator, I think that an object 
iterator form of closure is more fundamental than the collection 
iterator. This allows the start object to be included in the results, so 
a root and all its kids would be returned by

root.closure(it | it.kids)

whereas all the kids could be returned by

root.kids->forall(kid | kid.closure(it | it.kids))->asSet()

The collection iterator is nonetheless useful allowing the shorter

root.kids->closure(it | it.kids)

An object iterator is of course a new concept and so might bypass the 
specification in terms of iterate ordanance.

Do you think it worth appending an update to Issue 13944 along these lines?

	Regards
		
		Ed Willink

---------------------------------------------------------------------
On Mon, 14 Jul 2008 15:59:16 -0400, Christian W. Damus wrote:

--------8<--------