Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [viatra-dev] Transformation API
Hi,

I like the fire* solution much better than the other, but I am still not sure what would be the best way to handle this issue. I would like to hear other opinions as well.
+1! I don't think we should stick too much to old VTCL stuff. The fire… convention makes a lot more sense to me. I also agree that ALAP and other constructs well known from MT and GT should have easily recognizable and usable representations in our API. After all, this new transformation engine is meant to build on years of MT and GT experience and we should strongly strive to make it as easily accessible as possible.
 
About the convenience methods: it would be 'strange' to have convenience methods for the seemingly more complex multivalued case and not for the single-valued case (where I don't see a way to do it). 
I can only parse this sentence up to the first parenthesis, from then on it doesn't make sense to me.

cheers
Istvan

--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group
 
Cheers,
Zoli
-- Zoltán Ujhelyi

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.09.27., at 18:15, bergmann@xxxxxxxxxx wrote:

Hi!

My suggestions are the following:

1. (Batch) Transformation Statements

- The name of "forall" does not reflect its most important property. We should find an alternative name. How about "forAllCurrent"?
- As a very common use case, there should be a primitive equivalent of ALAP execution, since "until(alwaysFalse)" is awkward to read and difficult to come up with. How about "repeatedly" or even "whilePossible"?

As an alternative, we should consider verb-like statements for firing activities, such as "fireOne" (instead of "choose"), "fireAllCurrent" (instead of "forAllCurrent" or "forall"), "fireWhilePossible" (instead of "until(alwaysFalse)" or "repeatedly"), "fireUntil" (instead of "until").

2. Model Manipulation Primitives

(First, a minor point: the wiki calls the EObject a "container" even in cases where it does not have to be, or even explicitly stated not to be a container. Probably a copy/paste bug, OR some serious misunderstanding on my part.)

I suggest that we should create convenience methods that complement the current createChild, addTo, move and remove manipulators with a simplified version in case of multi-valued references: instead of the now owner EObject and the EReference, we could take a single EList as input. We can make sure with generic arguments that the list type is correct, and a single run-time instanceof check can verify whether the list is a containment list.

Cheers,
Gábor


To: Viatra developer discussions project <viatra-dev@xxxxxxxxxxx>
From: Ujhelyi Zoltán
Date: 09/20/2013 05:06PM
Subject: [viatra-dev] Transformation API

Hi,

as promised, I have set up a wiki page that describes the current transformation API implementation: http://wiki.eclipse.org/VIATRA2/EMF/Transformation_API

The implementation is in an early stage, everything is open to discussion; the page contains links to both the transformation API implementation and the TTC2013 example code.

Cheers,
Zoltán
-- Zoltán Ujhelyi

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

_______________________________________________
viatra-dev mailing list
_______________________________________________
viatra-dev mailing list

_______________________________________________
viatra-dev mailing list

Back to the top