[viatra-dev] Válasz: Re: Transformation API

["Varro, Daniel" <varro@xxxxxxxxxx>]

Szia Zoli

A MODELS alatt kuldok en is nehany tovabbi (strategiai) kommentet

Udv, Dani

Az üzenetet Samsung mobileszközről küldték

-------- Original message --------
Subject: Re: [viatra-dev] Transformation API 
From: Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx> 
To: Viatra project developer discussions <viatra-dev@xxxxxxxxxxx> 
CC:

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

_______________________________________________
viatra-dev mailing list
viatra-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/viatra-dev