Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 nicolas.lalevee@hibnet.org does not designate 216.86.168.182 as permitted
 sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Modification of Ant API for AntDSL
From: =?iso-8859-1?Q?Nicolas_Lalev=E9e?= <nicolas.lalevee@hibnet.org>
In-Reply-To: <0664E258-D6BE-4906-9BEB-D85B3F976A8D@hibnet.org>
Date: Sat, 28 Jul 2012 19:35:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A45D043D-7848-40AA-B93F-D7FBB9AF7E98@hibnet.org>
References: <34A7A68A-B91F-4F07-AA80-C7EDEAC231D5@hibnet.org>
 <87a9ykf0st.fsf@v35516.1blu.de>
 <0664E258-D6BE-4906-9BEB-D85B3F976A8D@hibnet.org>
To: "Ant Developers List" <dev@ant.apache.org>

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 =E0 19:20, Nicolas Lalev=E9e a =E9crit :

>=20
> Le 28 juil. 2012 =E0 15:54, Stefan Bodewig a =E9crit :
>=20
>> On 2012-07-28, Nicolas Lalev=E9e wrote:
>>=20
>>> 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.
>>=20
>> Sorry, I haven't found the time to play with it.
>=20
> 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=3D=
co&revision=3D1362284&content-type=3Dtext%2Fplain&pathrev=3D1362284
>=20
>>=20
>>> 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.
>>=20
>>> 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.
>>=20
>> I think the props Antlib can already do quite a bit of this.
>=20
> Actually I work at different level. See below.
>=20
>>> 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.
>>=20
>> 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.
>=20
> 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).
>=20
> 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.
>=20
>>> 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().
>>=20
>> Do you see any chance to unify this with PropertyHelpers?
>>=20
>>> The changes I suggest should obviously be backward compatible.
>>=20
>> Not so obvious to me.  Aren't there any APIs that return String but
>> would return Object with your changes?
>=20
> I think that the API are already returning Object, which is cool. But =
I would need setter of Object.
>=20
> Thank you for your feedback.
>=20
> Nicolas
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org