Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » USE_TYPE_CACHES and DYNAMIC_DISPATCH break basic OCL operations?
USE_TYPE_CACHES and DYNAMIC_DISPATCH break basic OCL operations? [message #1257548] Wed, 26 February 2014 15:05 Go to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Hi there,

before I enter the following report to the bugzilla, I want to ask if this is really a bug or maybe reported already. A complete example Project is attached below. In the following, I want to explain only important things.

Consider two classes: "Base" and "Derived". Both have an operation "op() : int" with OCL Body (invocation delegate, LPG). "op()" of "Base" shall simply return "1", "op()" of "Derived" shall return "2". I enable DYNAMIC_DISPATCH in order to enable common object-oriented bahavior, i.e., returning "2", if the object type is "Derived". So, only if this option is enabled, the following query call returns 2.

		// create object
		Derived m = PackFactory.eINSTANCE.createDerived();

		// dynamic invocation (dynamic: result=2, non-dynamic: result=1)
		QueryDelegate query1 = queryFactory.createQueryDelegate(m.eClass(),
				null, "self.oclAsType(Base).op()");
		System.out.println(query1.execute(m, null));


This works fine...

However, consider the following code:

		QueryDelegate query2 = queryFactory.createQueryDelegate(m.eClass(),
				null, "Set {self}->union(Set {self}).oclAsType(Base).op()");
		System.out.println(query2.execute(m, null));


Currently (5.0.0M5), this returns "invalid".
The query works with DYNAMIC_DISPATCH disabled, i.e., "{1}" is returned.
With DYNAMIC_DISPATCH disabled, I expect "{2}".

Investigating this issue leads to the following lines "EvaluationVisitorImpl.visitOperationCallExp":

		if (cachedTypeChecker != null) {
			C dynamicSourceType = getEvaluationEnvironment().getType(sourceVal);
			oper = cachedTypeChecker.getDynamicOperation(dynamicSourceType, oper);
			if (oper == null) {			// Ambiguous overload
				return getInvalid();
			}
		}


The cached type checker is active, so it is using the type checker even for the OCL standard operation "union". However, the type checker returns null... *bang*. Furhter lines which actually handle "union" are not processed any more.

---------

Other questions I have:

Q1: Is it true, that DYNAMIC_DISPATCH is only working with USE_TYPE_CACHES?

Q2: Is it true, that the only reason for USE_TYPE_CACHES is DYNAMIC_DISPATCH? Exist other advantages of using USE_TYPE_CACHES?

Q3: It was a horror for me creating the example project, because it was hard for me enabling both Options. I expected that the following code works:

		DelegateEPackageAdapter ePackageAdapter = DelegateEPackageAdapter
				.getAdapter(m.eClass().getEPackage());
		OCLDelegateDomain delegateDomain = (OCLDelegateDomain) ePackageAdapter
				.getDelegateDomain(OCLConstants.OCL_DELEGATE_URI_LPG);
		ParsingOptions.setOption(delegateDomain.getOCL().getEnvironment(),
				ParsingOptions.USE_TYPE_CACHES, Boolean.TRUE);
		EvaluationOptions.setOption(delegateDomain.getOCL()
				.getEvaluationEnvironment(),
				EvaluationOptions.DYNAMIC_DISPATCH, Boolean.TRUE);


However, there are some issues... the delegate domain is recreated... or whatever, and the options are gone again. If you want to know what I am talking about, just enable those lines in the example project. Dynamic dispatching won't work. Therefore, I had to create own environments and factories (regular, evaluation and OCL domain)... just for two options! Is this a bug, so should my previously mentioned code work?

  • Attachment: Test.rar
    (Size: 13.17KB, Downloaded 137 times)

[Updated on: Wed, 26 February 2014 15:06]

Report message to a moderator

Re: USE_TYPE_CACHES and DYNAMIC_DISPATCH breaks basic OCL operations? [message #1257718 is a reply to message #1257548] Wed, 26 February 2014 18:21 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The darker corners of Classic OCL contain problems that are too hard to
solve. This is one of the motivations for re-engineering the Pivot-based
OCL.

In your particular case, I think you a re demonstrating that using Java
Set semantics does not work for nested collections. You should find that
it works with the Pivot evaluator.

Yes. There probably is a Bugzilla waiting to be WONTFIXed once the Pivot
gets promoted from examples quality.

Regards

Ed Willink


On 26/02/2014 15:05, Kirsten M. Z. wrote:
> Hi there,
>
> before I enter the following report to the bugzilla, I want to ask if this is really a bug or maybe reported already. A complete example Project is attached below. In the following, I want to explain only important things.
>
> Consider two classes: "Base" and "Derived". Both have an operation "op() : int" with OCL Body (invocation delegate, LPG). "op()" of "Base" shall simply return "1", "op()" of "Derived" shall return "2". I enable DYNAMIC_DISPATCH in order to enable common object-oriented bahavior, i.e., returning "2", if the object type is "Derived". So, only if this option is enabled, the following query call returns 2.
>
> // create object
> Derived m = PackFactory.eINSTANCE.createDerived();
>
> // dynamic invocation (dynamic: result=2, non-dynamic: result=1)
> QueryDelegate query1 = queryFactory.createQueryDelegate(m.eClass(),
> null, "self.oclAsType(Base).op()");
> System.out.println(query1.execute(m, null));
>
> This works fine...
>
> However, consider the following code:
>
> QueryDelegate query2 = queryFactory.createQueryDelegate(m.eClass(),
> null, "Set {self}->union(Set {self}).oclAsType(Base).op()");
> System.out.println(query2.execute(m, null));
>
> Currently (5.0.0M5), this returns "invalid".
> The query works with DYNAMIC_DISPATCH disabled, i.e., "{1}" is returned.
> With DYNAMIC_DISPATCH disabled, I expect "{2}".
>
> Investigating this issue leads to the following lines "EvaluationVisitorImpl.visitOperationCallExp":
>
> if (cachedTypeChecker != null) {
> C dynamicSourceType = getEvaluationEnvironment().getType(sourceVal);
> oper = cachedTypeChecker.getDynamicOperation(dynamicSourceType, oper);
> if (oper == null) { // Ambiguous overload
> return getInvalid();
> }
> }
>
> The cached type checker is active, so it is using the type checker even for the OCL standard operation "union". However, the type checker returns null... *bang*. Furhter lines which actually handle "union" are not processed any more.
>
> ---------
>
> Other questions I have:
>
> Q1: Is it true, that DYNAMIC_DISPATCH is only working with USE_TYPE_CACHES?
>
> Q2: Is it true, that the only reason for USE_TYPE_CACHES is DYNAMIC_DISPATCH? Exist other advantages of using USE_TYPE_CACHES?
>
> Q3: It was a horror for me creating the example project, because it was hard for me enabling both Options. I expected that the following code works:
>
> DelegateEPackageAdapter ePackageAdapter = DelegateEPackageAdapter
> .getAdapter(m.eClass().getEPackage());
> OCLDelegateDomain delegateDomain = (OCLDelegateDomain) ePackageAdapter
> .getDelegateDomain(OCLConstants.OCL_DELEGATE_URI_LPG);
> ParsingOptions.setOption(delegateDomain.getOCL().getEnvironment(),
> ParsingOptions.USE_TYPE_CACHES, Boolean.TRUE);
> EvaluationOptions.setOption(delegateDomain.getOCL()
> .getEvaluationEnvironment(),
> EvaluationOptions.DYNAMIC_DISPATCH, Boolean.TRUE);
>
> However, there are some issues... the delegate domain is recreated... or whatever, and the options are gone again. If you want to know what I am talking about, just enable those lines in the example project. Dynamic dispatching won't work. Therefore, I had to create own environments and factories (regular, evaluation and OCL domain)... just for two options! Is this a bug, so should my previously mentioned code work?
>
>
Re: USE_TYPE_CACHES and DYNAMIC_DISPATCH breaks basic OCL operations? [message #1257917 is a reply to message #1257718] Wed, 26 February 2014 23:14 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
> In your particular case, I think you a re demonstrating that using Java
> Set semantics does not work for nested collections.

Don't know what you mean exactly... I think, that's a trivial bug, but haven't investigated too deep yet.

> This is one of the motivations for re-engineering the Pivot-based OCL.

Do you really mean re-engeneering the pivot-based OCL, so create a "version 2" pivot-based OCL? Or do you mean dumping classic OCL and making pivot-based OCL the better choice?

The first answer to my questions is almost always like, why not using the newer pivot-based. Unfortunately, pivot-based OCL has never been an option for me. It is simply too big. It does not work on Android devices. It has too many dependencies, so the limit of having 65535 methods is exceeded by far. My Android device laughed at me, when I told him to run that stuff... Using classic OCL is possible on the other hand. Too bad that the project has been cancelled.
Re: USE_TYPE_CACHES and DYNAMIC_DISPATCH breaks basic OCL operations? [message #1258185 is a reply to message #1257917] Thu, 27 February 2014 06:19 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

On 26/02/2014 23:14, Kirsten M. Z. wrote:
>> In your particular case, I think you a re demonstrating that using
>> Java Set semantics does not work for nested collections.
>
> Don't know what you mean exactly... I think, that's a trivial bug, but
> haven't investigated too deep yet.
The problem is equality. Java Sets must observe uniqueness by Java
equality. OCL sets by OCL equality. The classic OCL switches to Java
equality once things nest.
>
>> This is one of the motivations for re-engineering the Pivot-based OCL.
>
> Do you really mean re-engeneering the pivot-based OCL, so create a
> "version 2" pivot-based OCL? Or do you mean dumping classic OCL and
> making pivot-based OCL the better choice?
Making the Pivot a better choice.
>
> The first answer to my questions is almost always like, why not using
> the newer pivot-based. Unfortunately, pivot-based OCL has never been
> an option for me. It is simply too big. It does not work on Android
> devices. It has too many dependencies, so the limit of having 65535
> methods is exceeded by far. My Android device laughed at me, when I
> told him to run that stuff... Using classic OCL is possible on the
> other hand. Too bad that the project has been cancelled.
One of many incomplete activities is the Xtext2LPG grammar
transformation to allow the Pivot-based OCL to use the faster and much
smaller LPG parser. This will probably make substantuial inroads on the
method count.

Regards

Ed Willink
Re: USE_TYPE_CACHES and DYNAMIC_DISPATCH breaks basic OCL operations? [message #1258238 is a reply to message #1258185] Thu, 27 February 2014 07:35 Go to previous message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
> One of many incomplete activities is the Xtext2LPG grammar
> transformation to allow the Pivot-based OCL to use the faster and much
> smaller LPG parser. This will probably make substantuial inroads on the
> method count.

Oh, wow! That's new to me. Looking forward to that Smile I will watch that...
Previous Topic:OCL expression evaluation as "LHS"
Next Topic:OCL and Xtext
Goto Forum:
  


Current Time: Tue Mar 19 09:01:01 GMT 2024

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

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

Back to the top