I have looked into the actual implementation details, actually I don't need much. So little that I have committed them, it will be easier to review, easier than writing about it in an email. If I can do this with a PropertyHelper, I'll revert and use the non intrusive way.
Nicolas Le 28 juil. 2012 à 19:35, Nicolas Lalevée a écrit : > I think that I would like to change is the following point as documented in > the header of the PropertyHelper class: > "Object value seems valuable as outlined." > > Nicolas > > Le 28 juil. 2012 à 19:20, Nicolas Lalevée a écrit : > >> >> Le 28 juil. 2012 à 15:54, Stefan Bodewig a écrit : >> >>> On 2012-07-28, Nicolas Lalevée wrote: >>> >>>> I start to like what I am doing which the AntDSL so I would like to >>>> modify a little bit the Ant API so I can avoid doing so work around. >>> >>> Sorry, I haven't found the time to play with it. >> >> No worry. >> Though some completely subjective opinion on the "look&feel" of the language >> will be appreciated :) >> Anyone ? this is usually a subject for troll :) >> http://svn.apache.org/viewvc/ant/sandbox/antdsl/trunk/test/build.ant?view=co&revision=1362284&content-type=text%2Fplain&pathrev=1362284 >> >>> >>>> In AntDSL, I have introduced an expression language so do some basic >>>> computing: some math, some logical computation and string manipulation >>>> for now. It is intended to replace the property expansion in strings. >>> >>>> Actually, the logical computation is already implemented in Ant: the >>>> Conditions tasks. So I have used them for the if/unless attributes of >>>> the target. I would like to take it back into Ant: [1]. I don't intend >>>> to replace the existing if/unless, just offer new Java API to Target. >>> >>> I think the props Antlib can already do quite a bit of this. >> >> Actually I work at different level. See below. >> >>>> I would also like to be able to have expressions in task >>>> attributes. But Ant assumes these are always Strings. As far as I can >>>> tell, there are two places where it is assumed and it would be >>>> changed: RuntimeConfigurable and IntrospectionHelper. I have been able >>>> to work around RuntimeConfigurable and provide my own >>>> implementation. But IntrospectionHelper is final. >>> >>> AFAIR this is not totally true, PropertyHelpers can return Objects and >>> they get picked up in the approriate places. It is true that >>> PropertyHelpers are the only way to generate non-String values outside >>> of IntrospectionHelper, though. This is rather limiting. >> >> I am not sure property helper will do the proper job. I have to admit I >> don't know them much, but as far I can tell, they are sort of String >> parsers. With Antdsl, the parser has already done the job, I get an instance >> of the "thing to evaluate", an AntExpression, which can wrap a Condition for >> instance. >> So when building an UnknownElement, my project helper cannot call >> RuntimeConfigurable#setAttribute(String, String) like >> ProjectHelper2.ElementHandler.onStartElement() does, I need a >> RuntimeConfigurable#setAttribute(String, AntExpression). Thus I would like >> to introduce a RuntimeConfigurable#setAttribute(String, Object). >> >> I have also an issue with macros which implement DynamicAttribute. But >> actually for AntDSL I think the best would be to reimplement the macros, >> since I am experimenting getting rid of the property expansion, and thus >> probably name them differently, "function" probably. >> >>>> I have not a patch to suggest, but I think the change would probably >>>> be about introducing an interface Evaluable, change everywhere from >>>> String to Object, and when we try to get the value of the attribute, >>>> if Evaluable call eval(), otherwise call .toString(). >>> >>> Do you see any chance to unify this with PropertyHelpers? >>> >>>> The changes I suggest should obviously be backward compatible. >>> >>> Not so obvious to me. Aren't there any APIs that return String but >>> would return Object with your changes? >> >> I think that the API are already returning Object, which is cool. But I >> would need setter of Object. >> >> Thank you for your feedback. >> >> Nicolas >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
