Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Using OCL for creating (temporary) object
Using OCL for creating (temporary) object [message #1130136] Wed, 09 October 2013 04:52 Go to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
Hi @all,

first, I have a more general question about an OCL feature I am missing. I recently recognized that it is not possible to create objects using OCL. To be honest, I was surprised. Or did I just miss this feature? I could not find any example or according documentation. Has this ever been in an OCL specification? Are there any (theoretical) issues/problems?

I have worked with Eclipse QVTo before, which is based on OCL resp. imperative OCL. It is common to create objects there, e.g. via

object ObjectType { name = 'objectName', attribute1 = 1, ... }


Maybe this feature is not that important in a regular OCL. However, why not having this feature? For example, there is no problem to create/use (temporary) collections or tuples:

let x : Tuple(name : String, att1 : Integer) = Tuple {name = 'a_name', attribute1 = 1} in ...


Another area of application would be a derived feature (or query method, no side effect), which is defined using OCL. The feature shall return a "derived" object, i.e., a data set based on a defined class type. Without the possibility to create the data set, this is not possible?

In addition, if creation would be possible, are there any EMF related problems? For example, if OCL (non-Pivot) is extended by such a feature, and EMF objects must be created (OclInEcore).
Re: Using OCL for creating (temporary) object [message #1130187 is a reply to message #1130136] Wed, 09 October 2013 05:47 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

This is https://bugs.eclipse.org/bugs/show_bug.cgi?id=293622 (2009),
http://www.omg.org/issues/ocl2-rtf#Issue13057 (2008).

If you read Bug 293622, you can see how my thinking has evolved so that
the side-effect-free issue is solved.

If OCL had had type constructors when QVTo was formulated, QVTo could
have been simpler.

The Pivot-based Eclipse OCL has a prototype implementation of type
constructors re-using the Tuple syntax. Currently it creates objects,
with a memory side effect; multiple creations return multiple objects,
except that if you use the OCL to Java code generator the Common
Subexpression Elimination may kick in. Consequently
"MyClass{name='mine'}=MyClass{name='mine'}" may be true or false
depending on your execution context.

The bug is still open since there is more work to do, but for typical
simple cases it may be useful.

This facility is unlikely to be available in the classic OCL.

There is no particular interaction with EMF, except that if you want to
construct an EDataType, you must implement createFromString to support
e.g. "EDate{'1-Jan-2013'}".

Regards

Ed Willink

On 09/10/2013 09:52, Kirsten M. Z. wrote:
> Hi @all,
>
> first, I have a more general question about an OCL feature I am
> missing. I recently recognized that it is not possible to create
> objects using OCL. To be honest, I was surprised. Or did I just miss
> this feature? I could not find any example or according documentation.
> Has this ever been in an OCL specification? Are there any
> (theoretical) issues/problems?
>
> I have worked with Eclipse QVTo before, which is based on OCL resp.
> imperative OCL. It is common to create objects there, e.g. via
>
> object ObjectType { name = 'objectName', attribute1 = 1, ... }
>
> Maybe this feature is not that important in a regular OCL. However,
> why not having this feature? For example, there is no problem to
> create/use (temporary) collections or tuples:
>
> let x : Tuple(name : String, att1 : Integer) = Tuple {name = 'a_name',
> attribute1 = 1} in ...
>
> Another area of application would be a derived feature (or query
> method, no side effect), which is defined using OCL. The feature shall
> return a "derived" object, i.e., a data set based on a defined class
> type. Without the possibility to create the data set, this is not
> possible?
>
> In addition, if creation would be possible, are there any EMF related
> problems? For example, if OCL (non-Pivot) is extended by such a
> feature, and EMF objects must be created (OclInEcore).
Re: Using OCL for creating (temporary) object [message #1130245 is a reply to message #1130187] Wed, 09 October 2013 06:56 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
Hi Ed,

thank you for sharing the current state. The thoughts within the issue/bug reports have also been very useful, and I share your opinion. I was aware of side effect issues during object initialization. However, object contruction with side effects cannot be found in my current project, for example. The use case where objects represent ("simple") data structures with trivial construction is very common, I think. Of course, some issues like object creation events etc. should be considered and omitted.

In order to use methods in OCL, you have to mark them (side-effect free, "query"). Strange that such considerations do not exist in the context of object creation.

I guess that maintaining the non-Pivot parser and evaluator in respect to such a featue is out of your scope?
Re: Using OCL for creating (temporary) object [message #1130332 is a reply to message #1130245] Wed, 09 October 2013 08:50 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

On 09/10/2013 11:56, Kirsten M. Z. wrote:
> In order to use methods in OCL, you have to mark them (side-effect
> free, "query"). Strange that such considerations do not exist in the
> context of object creation.
True object creation is not side-effect free, so no consideration needed.

The evolution of thinking in Bug 293622 enables a restricted form of
object creation to happen without a side-effect.
>
> I guess that maintaining the non-Pivot parser and evaluator in respect
> to such a featue is out of your scope?
I don't have enough time for the Pivot functionality as it is. More than
trivial compatibility tracking of the Classic OCL will only happen if
somebody provides additional manpower.

Since every change to the Classic OCL takes much much longer than you
would expect because of compatibility concerns, I doubt that it will
ever be practical to accommodate the OMG-defined models and general
cleanups that will form part of OCL 2.5 without causing significant
legacy upset. The Pivot functionality is there for those wanting to see
progress at the expense of being bleeding edge.

Regards

Ed Willink
Previous Topic:Checking an OCL constraint before actually setting the value
Next Topic:OCL Validation outside of eclipse
Goto Forum:
  


Current Time: Thu Jul 24 11:30:54 EDT 2014

Powered by FUDForum. Page generated in 0.04128 seconds