Re: [viatra-dev] Transformation API

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Thanks for the comments.

1. The naming of forall and until elements was very hard to come up with, and at a final solution before opening up the discussion I tried to rely on the old VTCL-keywords as a placeholder (but iterate did not work well). Forall was extremely hard to tackle, as most sensible names would be hard to distinguish between the forall and alap execution modes.

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.

2. Minor point: yes, it is copy-paste. The mediawiki table syntax is something awful, I did not want to see it more the absolutely required.

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). Additionally, in my limited experience with the transformation, type safety did not matter too much.

As a final thought: this was the part where I said that this API will be awkward, no matter what we do, so maybe we should aim for a simple, functional API that is easily translatable to an upcoming, real transformation language.

Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

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
> 
> 
> -----viatra-dev-bounces@xxxxxxxxxxx wrote: -----
> To: Viatra developer discussions project <viatra-dev@xxxxxxxxxxx>
> From: Ujhelyi Zoltán 
> Sent by: viatra-dev-bounces@xxxxxxxxxxx
> 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
> https://www.inf.mit.bme.hu/en/members/ujhelyiz
> 
> Fault Tolerant Systems Research Group
> Budapest University of Technology and Economics
> 
> _______________________________________________
> viatra-dev mailing list
> viatra-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/viatra-dev
> _______________________________________________
> viatra-dev mailing list
> viatra-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/viatra-dev