ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [DISC] ${} expansion for data types
Date Tue, 29 May 2001 09:10:29 GMT
At 10:42 AM 5/29/01 +0200, Stefan Bodewig wrote:
>We've agreed to unify the namespace of properties and all other
>data types - now what are we going to do with ${} expansions, that are
>expected to yield a String result.

I would disagree with that. A ${} will expand to an object - this *could*
be converted to a string if it was embedded in a string.

ie The second use of myfileset will not be converted if src expects the
type to be fileset.

<mytask an-attribute="This will convert to string - ${myfileset}" 
        src="${myfileset}"/> 

>IMHO for Ant1 like properties it should simply be the String itself.

So String->String? sounds good to me ;)

>Likewise, there are some data types where calling the toString method
>of the corresponding Object may be enough (like Path, which already
>takes the OS into account).  For some I don't think a ${} expansion is
>useful at all, but my fantasy is probably too limited 8-).
>
>For all the non-obvious cases we've agreed on pluggable converters (at
>least that is my understanding of it 8-).  So Ant would try to lookup
>a converter for a given data-type and fall back to using the toString
>method if it cannot find one, right?

thats my understanding of it.

>There are cases where the result a user wants from a ${} expansion
>depends on the context.  If you take FileSet for example, people have
>asked for lists of absolute or relative paths, separated by a host of
>different delimiters.

yup.

>Does that mean, we want/have to make the converters a hierarchical
>aspect?

Not in my opinion - they just have to be aware of the context in which they
are called. (ie we have to pass in the properties at time they are
converted). Context could be hierarchial (or it could not) but that is
irrelevent to the converter. It is not an aspect because it does not change
a horizontal/form cut in problem space but instead offers a
vertical/content feature.


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message