Community
Participate
Working Groups
One nice thing about accessing Java objects from EOL is that if we have the usual pair of getX/setX methods, we can use variable.x to get and set the property. For example, if type A has getName() and setName(String), we can just do: var x = new Native("A"); ("My name is: " + x.name).println(); x.name := 'OtherName'; This is quite convenient. To be consistent, perhaps we should allow the same convenience for model types and their context operations. For instance, we could alias the "name" attribute in type A to "title" with: operation A getTitle() : String { return self.name; } operation A setTitle(newTitle : String) { self.name := newTitle; } And then we could do something like this: var x = new A; ("Title: " + x.title).println(); x.title := 'B';
I'm not sure about this one. I can't think of a time when I would use this (though I am worryingly low on caffeine right now). Did you have a specific example in mind Antonio? If we do decide to implement this, we'll need to be careful not to break existing code. For example, at the minute the following code prints data from the model: x.name.println(); operation A getName() : String { return "foo"; } We'd need to ensure that implementing this feature does not result in the above program invoking getName() and hence printing "foo".
One case for this is when the value is not directly available in a model element: since we need to go through several other objects that are connected to the model element and compute some information, we will usually define our get/set methods for this case. For instance, I have a "ServiceActivity" class which can be annotated by a separate "PerformanceAnnotation", which has a timeLimit attribute. Some ServiceActivities may lack an annotation: in that case, getTimeLimit() must return a default value. Likewise, setTimeLimit(limit) may need to create a PerformanceAnnotation and link it to the ServiceActivity on the fly, before changing the timeLimit attribute in the annotation. Simply using "timeLimit" as if it were a regular attribute would look much cleaner. As for the risk of calling the wrong method, we could follow the same approach as in the JavaPropertyGetter and JavaPropertySetter. First, we try to access the proper attribute. If that doesn't work, then we check the property. That would get rid of the ambiguity.
(In reply to comment #2) > For instance, I have a "ServiceActivity" class which can be annotated by a > separate "PerformanceAnnotation", which has a timeLimit attribute. Some > ServiceActivities may lack an annotation: in that case, getTimeLimit() must > return a default value. Likewise, setTimeLimit(limit) may need to create a > PerformanceAnnotation and link it to the ServiceActivity on the fly, before > changing the timeLimit attribute in the annotation. Simply using "timeLimit" as > if it were a regular attribute would look much cleaner. I forgot to mention that getTimeLimit/setTimeLimit would use a ServiceActivity as their context, rather than a PerformanceAnnotation.
(In reply to comment #2) > As for the risk of calling the wrong method, we could follow the same approach > as in the JavaPropertyGetter and JavaPropertySetter. First, we try to access > the proper attribute. If that doesn't work, then we check the property. That > would get rid of the ambiguity. Great, I think that this would definitely be preferable. I must admit that I'm still not sure whether I'd use this or not, but if it doesn't break existing code or complicate maintenance in the future, I think there's absolutely no harm in adding it.
I'm only worried that this will slow down execution as for every property invokation all the user-defined operations will need to be introspected as well. Antonio: Would this help for your scenario? http://www.springerlink.com/content/q353020983320427/
Hi Dimitris, (In reply to comment #5) > I'm only worried that this will slow down execution as for every property > invokation all the user-defined operations will need to be introspected as > well. > > Antonio: Would this help for your scenario? > http://www.springerlink.com/content/q353020983320427/ Well, that is a very interesting approach! I'll note it down for later reference. However, this still forces the user to use a separate custom metamodel, and I'm currently working with the MARTE metamodel from the Papyrus project, so I can't really use that approach in this case. In any case, this would be a fallback case, so I believe performance should not really be affected except for the cases when we would throw an exception saying "property not found" right now. What do you think? Another option is to run all test cases a few times, sum up the clock time, switch to the modified version, try it again and see if there are any important differences. Doing that with git-svn is quite easy: I just need to switch branches and try them out.
Louis, Dimitris: have you thought a bit more about this? Shall I give it a try and compare the average running times over 5 runs of both test suites?
I'm happy with that.
(In reply to comment #8) > I'm happy with that. +1
In today's telecon, Dimitris has suggested that the EOL context operations take precedence over the Java ones. If the Java operations took precedence over the EOL context operations, x.getTitle would call the Java operation, and x.title would call the getTitle context operations. We should have it call the getTitle context operation in both cases. This would introduce an inconsistency. However, doing the right thing in this case might introduce a performance issue. I'll have to open a new branch in my Git mirror and evaluate its impact.
