Re: [qvto-dev] coerceValue()

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

This is part of some Classic OCL functionality.

It is used to correct an 'erroneous' object representation so that what is available is Ecore compatible.

Quite what is 'erroneous' and quite when the conversions are performed is unclear.

The functionality is fundamentally wrong. Conversions should be controlled by the known rather than deduced type of the data. Using data object analysis is wrong and contributes to the eGet() return of a list gives an NPE/CCE phenomenon.

Not sure if that helps.

In the new Pivot implementation, we have nearly the same problem, but here we have

- boxed values, the internal representation for which Java' Object.equals(Object) is sound
- unboxed values, the external/Ecore representation for which Java' Object.equals(Object) may be unsound

For most values boxed and unboxed values need no conversion. When needed, conversion is performed by the IdResolver. See 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=448470

for further work pending.

In Juno everything got boxed, which proved very expensive. Every EObject wrapped in an ObjectValue. Now in Luna boxing is very selective; mostly just numbers. CollectionValues need further optimization.

NB. Classic QVTo/OCL does not support arbitrary size integers or Integer/Real equivalence. Pivot OCL, and consequently Pivot QVTo will.

Internally, all Evaluator visits pass boxed values. This includes Standard Library Operation calls.

Externally, anything with an Ecore-compatible interaction passes unboxed values. This includes model operation calls and property references.

Sorry, this isn't as well documented as it should be and some comments may be adrift as I have endeavoured to do less and less boxing and so incur lower and lower overheads. The best documentation is the assertIsBoxed/assertIsUnboxed calls.

    Regards

        Ed Willink

On 31/10/2014 14:39, Liu, H. wrote:

Dear QVTo developers:

 

I’m from a group of people who are working on optimizing QVTo engine recently.

 

We profiled the QVTo engine.

 

One of the method we found that takes time is the coerceValue() method.

It is located in

 

After some investigation, I’m still not exactly clear about what this method is used for.

 

The coerceValue(ETypedElement element, Object value, boolean copy) method is called in two places,

 

the callOperation() method and the navigateProperty() method.

 

In both call, the parameter copy is set to true.

For my understanding, this means if the parameter value is of type collection, it will be copied to a new collection as an output.

 

So my question is why this parameter is always set to true?

Is there possibilities that this parameter can be set to false, so it don’t need to create new collections, which might save time?

 

Best regards,

Hang

_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5315 / Virus Database: 4189/8484 - Release Date: 10/31/14