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
