| Re: [amp-dev] Back to work |
Hi Jonas, including amp-dev list. Please see my msg: The approach I'm talking about there is allowing people to have a kind of "Method" action (perhaps we need another action for this) as a behavior provider and be able to mark it in model for not regenerating (or it would only be generated once by default). This would be a discrete piece of code that would work something like: interface IBehaviorProvider { perform(Object object); } public class EatFoodBehaviorProvider implements IBehaviorProvider { perform(Object object) { ((MetabolicAgent) object).performOnAgent(); } //this is just a convenience method to have agent already cast.. performOnAgent(MetabolicAgent agent) { Do something... } } Then of course code would be generated to call the provider from the agent class. In a way this, is just additional sugar support for the recommended practice which is to simply always write a method body so it looks like this: //In agent.. MetabolicAgentHelper.eatFood(this); public class MetabolicAgentHelper() { public static void eatFood() { Do something... ... } } But I just realized that you probably mean being able to change generated behavior for a whole set of actions. In that case I think we can still handle it without @generated as part of a nice general solution that fits in very well with the idea of being able to use plain EMF Ecore models or any arbitrary model with no behavior in it (like an Enterprise Java Bean for example). We could generate *all* behavior this way and then that behavior would work regardless of whether people were generating the structure code using AMP or using it from some place else! And then as above people could always mark the model at the root action level to not be regenerated. Hmm..we could even support dynamic method invocation and injectable invocation that way.. But I realize that there are some advantages to being able to do this from code as well. If we used the provider approach we could check for an @generated method for the .. wait...that gives me an idea about to handle this, but it would take some more engineering. See the XPand thread where I'll follow up on that. cheers, Miles On Nov 25, 2010, at 8:09 AM, Jonas Ruettimann wrote: [SNIP]
|