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
