Eclipse Community Forums: QVT-OML » intermediate classes in library?

Help

Home

Home » Modeling » QVT-OML » intermediate classes in library?

Show: Today's Messages :: Show Polls :: Message Navigator

intermediate classes in library? [message #1694284]

Mon, 04 May 2015 07:48

Thomas Busch

Messages: 23
Registered: November 2014

Junior Member

Hi,

here comes my presumably last question:

Is it possible to put intermediate classes and the function which use them into a library?

I have an intermediate class to create some intermediate results which are later used and which should not be in the target-model themself. Sadly I am not able to put the class and the functions into a library with the error "Intermediate classifier definition is allowed only for transformation".

I think it might be possible to put the intermediate class into a transformation and extend my transformation by that one, but I do not like that structure and would like to import everything from libraries.

Regards
Thomas

Report message to a moderator

Re: intermediate classes in library? [message #1694308 is a reply to message #1694284]

Mon, 04 May 2015 10:31

Ed Willink

Messages: 7669
Registered: July 2009

Senior Member

Hi

I don't use intermediate classes, certainly not for any non-trivial
purpose. I consider them to be unhelpful inferior language bloat.

Much better to design a proper Ecore model with whatever facilities you
want in it.

Regards

Ed Willink

On 04/05/2015 08:48, Thomas Busch wrote:
> Hi,
>
> here comes my presumably last question:
>
> Is it possible to put intermediate classes and the function which use
> them into a library?
> I have an intermediate class to create some intermediate results which
> are later used and which should not be in the target-model themself.
> Sadly I am not able to put the class and the functions into a library
> with the error "Intermediate classifier definition is allowed only for
> transformation".
>
> I think it might be possible to put the intermediate class into a
> transformation and extend my transformation by that one, but I do not
> like that structure and would like to import everything from libraries.
>
> Regards
> Thomas

Report message to a moderator

Re: intermediate classes in library? [message #1694407 is a reply to message #1694308]

Tue, 05 May 2015 07:49

Thomas Busch

Messages: 23
Registered: November 2014

Junior Member

ok, I totally understand your opinion.
I just have the problem, that I cannot change the source or target metamodel and I think creating an inbetween-metamodel and doing 2 transformation would even confuse more

Report message to a moderator

Re: intermediate classes in library? [message #1694444 is a reply to message #1694407]

Tue, 05 May 2015 11:33

Ed Willink

Messages: 7669
Registered: July 2009

Senior Member

Hi

I don't see why you have two transformations.

QVTo allows you to code multiple passes, so rather than multiple passes
to/from QVTo-defined intermediate classes, you have multiple passes
to/from Ecore-defined 'intermediate' classes.

Regards

Ed Willink

On 05/05/2015 08:49, Thomas Busch wrote:
> ok, I totally understand your opinion. I just have the problem, that I
> cannot change the source or target metamodel and I think creating an
> inbetween-metamodel and doing 2 transformation would even confuse more

Report message to a moderator

Re: intermediate classes in library? [message #1695252 is a reply to message #1694444]

Wed, 13 May 2015 05:49

Thomas Busch

Messages: 23
Registered: November 2014

Junior Member

I am not sure if I get what you mean.
Is there only one "transformation(in source:A, out target:B);" with only one in and one out model?
I assume I have to create the 'intermediate' Ecore-defined classes with:

metamodel MyClass
{
...
}

Report message to a moderator

Re: intermediate classes in library? [message #1695255 is a reply to message #1695252]

Wed, 13 May 2015 06:10

Ed Willink

Messages: 7669
Registered: July 2009

Senior Member

Hi

I'm not sure that I understand your words.

You can have multiple in/out or inout models.

Regards

Ed Willink

On 13/05/2015 06:49, Thomas Busch wrote:
> I am not sure if I get what you mean. Is there only one
> "transformation(in source:A, out target:B);" with only one in and one
> out model?
> I assume I have to create the 'intermediate' Ecore-defined classes with:
>
> metamodel MyClass
> {
> ..
> }

Report message to a moderator

Re: intermediate classes in library? [message #1695547 is a reply to message #1695255]

Sat, 16 May 2015 08:36

Thomas Busch

Messages: 23
Registered: November 2014

Junior Member

ok, so my transformation might look like this?

transformation(in source:A, inout intermediateMdl:C, out target:B);

Report message to a moderator

Re: intermediate classes in library? [message #1695943 is a reply to message #1694308]

Wed, 20 May 2015 12:43

Christopher Gerking

Messages: 116
Registered: April 2011

Senior Member

I actually filed an OMG issue on exactly this topic years ago: http://www.omg.org/issues/qvt-rtf.clos.html#Issue18325

Ed Willink wrote on Mon, 04 May 2015 06:31

I don't use intermediate classes, certainly not for any non-trivial
purpose. I consider them to be unhelpful inferior language bloat.

Can't reproduce. They are very helpful to store intermediate data, which doesn't make it into your target model, but is still required to build up that target model.

Ed Willink wrote on Mon, 04 May 2015 06:31

Much better to design a proper Ecore model with whatever facilities you
want in it.

Intermediate classes actually are a proper Ecore model, which just emerges dynamically from the textual syntax used in QVTo. I consider an external Ecore to be an unnecessary overhead.

I still don't see a reason why intermediate classes should be restricted to transformations, and excluded for libraries.

Report message to a moderator

Re: intermediate classes in library? [message #1695948 is a reply to message #1695943]

Wed, 20 May 2015 13:41

Ed Willink

Messages: 7669
Registered: July 2009

Senior Member

Hi

Your issue asked the question. It did not ask for a change. The
resolution answered the question in accordance with the prevailing
wording. And added:

"Future: if the dual Package/Class inheritance of Module is resolved to
make Library Package-like and
OperationalTransformation Class-like, promoting intermediates to Module
will create more problems to
solve."

Eclipse QVTd trims a QVTc/QVTr Transformation to be just a Class and
wrapping it in a Package appears to work fine. The only issue is whether
an implicitly named wrapping Package is unnamed or duplicates the
transformation name.

Current work on the Pivot-zed QVTo seems to come to the same conclusion.

Therefore if a Library evolves to be Package-like, intermediate classes
would appear to be no problem.

But one major problem with the current QVTo metmodels are that they are
very limited (no 'unique' collections) and severely underspecified
('ordered' not in the grammar). Chasing 100% of relevant UML
functionality is probably a loser; I can see a case for adding
StateMachines. But providing a lightweight capability for richer data
declarations could be useful.

If you provide a motivating example, it might be clearer what is needed.
Contrast the two approaches, forced use of an external model wrt use of
an internal model. Would the internal model be re-useable?

Regards

Ed Willink

On 20/05/2015 13:43, Christopher Gerking wrote:
> I actually filed an OMG issue on exactly this topic years ago:
> http://www.omg.org/issues/qvt-rtf.clos.html#Issue18325
>
> Ed Willink wrote on Mon, 04 May 2015 06:31
>> I don't use intermediate classes, certainly not for any non-trivial
>> purpose. I consider them to be unhelpful inferior language bloat.
>
>
> Can't reproduce. They are very helpful to store intermediate data,
> which doesn't make it into your target model, but is still required to
> build up that target model.
>
> Ed Willink wrote on Mon, 04 May 2015 06:31
>> Much better to design a proper Ecore model with whatever facilities
>> you want in it.
>
>
> Intermediate classes actually are a proper Ecore model, which just
> emerges dynamically from the textual syntax used in QVTo. I consider
> an external Ecore to be an unnecessary overhead.
>
> I still don't see a reason why intermediate classes should be
> restricted to transformations, and excluded for libraries.

Report message to a moderator

Re: intermediate classes in library? [message #1696608 is a reply to message #1695948]

Wed, 27 May 2015 13:29

Christopher Gerking

Messages: 116
Registered: April 2011

Senior Member

Very interesting to see that intermediates were once supported in Eclipse QVTo even for libraries, but then abolished to align with the OMG specification: https://bugs.eclipse.org/bugs/show_bug.cgi?id=261533

[Updated on: Wed, 27 May 2015 13:31]

Report message to a moderator

Re: intermediate classes in library? [message #1696624 is a reply to message #1696608]

Wed, 27 May 2015 14:14

Ed Willink

Messages: 7669
Registered: July 2009

Senior Member

On 27/05/2015 14:29, Christopher Gerking wrote:
> Very interesting to see that intermediates very once supported in
> Eclipse QVTo even for libraries, but then abolished to align with the
> OMG specification: https://bugs.eclipse.org/bugs/show_bug.cgi?id=261533
Indeed.

This seems to be yet another example of implementers thinking that the
specifiers are infallible. An issue should have been raised then.

Regards

Ed

Report message to a moderator

Previous Topic:	Transformation via Java class: Import Library?
Next Topic:	Call qvto in Java : applyStereotype() does not work

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Sep 10 07:30:32 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter