Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-OML » intermediate classes in library?
intermediate classes in library? [message #1694284] Mon, 04 May 2015 07:48 Go to next message
Thomas Busch is currently offline Thomas BuschFriend
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
Re: intermediate classes in library? [message #1694308 is a reply to message #1694284] Mon, 04 May 2015 10:31 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5393
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
Re: intermediate classes in library? [message #1694407 is a reply to message #1694308] Tue, 05 May 2015 07:49 Go to previous messageGo to next message
Thomas Busch is currently offline Thomas BuschFriend
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
Re: intermediate classes in library? [message #1694444 is a reply to message #1694407] Tue, 05 May 2015 11:33 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5393
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
Re: intermediate classes in library? [message #1695252 is a reply to message #1694444] Wed, 13 May 2015 05:49 Go to previous messageGo to next message
Thomas Busch is currently offline Thomas BuschFriend
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
{
...
}
Re: intermediate classes in library? [message #1695255 is a reply to message #1695252] Wed, 13 May 2015 06:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5393
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
> {
> ..
> }
Re: intermediate classes in library? [message #1695547 is a reply to message #1695255] Sat, 16 May 2015 08:36 Go to previous messageGo to next message
Thomas Busch is currently offline Thomas BuschFriend
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);
icon13.gif  Re: intermediate classes in library? [message #1695943 is a reply to message #1694308] Wed, 20 May 2015 12:43 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 57
Registered: April 2011
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.
Re: intermediate classes in library? [message #1695948 is a reply to message #1695943] Wed, 20 May 2015 13:41 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5393
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.
Re: intermediate classes in library? [message #1696608 is a reply to message #1695948] Wed, 27 May 2015 13:29 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 57
Registered: April 2011
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 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5393
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
Previous Topic:Transformation via Java class: Import Library?
Next Topic:Call qvto in Java : applyStereotype() does not work
Goto Forum:
  


Current Time: Wed Sep 20 11:16:45 GMT 2017

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

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