[Xcore] specifying a setter for a many-valued derived feature [message #1751769] |
Fri, 13 January 2017 11:11  |
Eclipse User |
|
|
|
Hi Ed, hi all,
I have something like this in Xcore:
class Coordinate
{
double x
double y
}
class Shape
{
contains Coordinate[] points
}
and I have the requirement to additionally have access to x and y coordinates as separate lists:
class Shape
{
contains Coordinate[] points
derived double[] xCoordinates
get {
points.map[x]
}
// same for y ...
}
Until here, everything seems to be fine.
Now, what I need is a setter as well and this is where I struggle.
I've tried with something like this:
derived double[] xCoordinates
get { /* ... */ }
set {
for (i : (0..points.size)) {
points.^get(i).x = (value as Iterable<Double>).^get(i)
}
}
but this fails silently (no error marker; the setXCoordinates() method is just not generated in Java and the Xcore parser seems to work a lot because I get small UI freezes every few moments).
What would be the correct syntax? Or is it forbidden to have a setter to a many-valued derived feature?
Thanks in advance for any hints!
Best,
Stefan
|
|
|
Re: [Xcore] specifying a setter for a many-valued derived feature [message #1751791 is a reply to message #1751769] |
Sat, 14 January 2017 00:17  |
Eclipse User |
|
|
|
Derived setters are really not well tested and given that a multi-valued features never have a generated setter, it doesn't seem so sensible. Also, even for the getter, there are parts of the framework that expect a multi-valued feature's return value to implement InternalEList, so even that part might case problems. You could define an operation that updates the points feature. Note that I think it's generally not a great idea to model a Point as a class. The overhead for an EObject seems excessive for two double values. And likely people programming against such an API will find it annoying to create a Coordinate set the two values, and they'll find it confusing that a Coordinate has a container and will be removed from one container when added to another...
|
|
|
Powered by
FUDForum. Page generated in 2.66793 seconds