ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simeon H.K. Fitch" <sim...@fitch.net>
Subject Re: Ant2 and properties
Date Tue, 05 Dec 2000 01:32:24 GMT
On Mon, Dec 04, 2000 at 03:57:13PM -0800, Jose Alberto Fernandez wrote:
> 
> -1 on this, eventhough I do not vote :-(. 
> How do I create a string that only contains the string value
> of the data-type property?

You must depend on the datatype supporting a resonable translation to
a string through the toString() method, just like Integer, Double,
Boolean, etc.

> What you are proposing is that the meaning of ${} depends on the context
> in which ${} is used. That to me is confusing and wrong. The meaning of
> a construct should be independent of the context in which is used,
> otherwise there will be no clear rules of composition of the features.

I disagree, as I think context is what data interpretation is all
about. Implicit meaning is irrelevant. Is "100" a String or a number?
Both, one or the other, or neither, depending on who you give the byte
array {'1', '0', '0' } to. However, it is perfectly fine for the
object to provide contextual hints as to what the meaning is, as is
done in the java.lang.Number class (byteValue(), doubleValue(),
shortValue(), etc.).

I would go even further to argue that *no* piece of data has a meaning
that is independent of the context in which it is used. For all I
know, a build.xml file may have artistic meaning to one person,
anthropological meaning to other, and only to Ant does it have
behavioral meaning (for humans it has desriptive or predictive meaning).

Nor do I think providing clear composition of rules is an issue. Let
me use the String example again. The composition

	"Fred " + new Double(4) + new StringBuffer(" foo ") + 3 + 4

Has a clear set of rules for evaluation. Each object in the addition
production can have it's own set of different meanings in different
contexts. It is just in this one that it evaluates to a single String
object. 

Therefore, I +1 on the use of ${} in more than one context. I do not
think that it should be valid in /all/ contexts, but the ones that
make sense (and "string" is one of them).

> 
> If you still want to do this kind of things, then you need to provide a
> different
> syntax for the construct. For example: $[somevar] for the object and
> ${somevar}
> for the string. This is just an example, it can be whatever other resonable
> syntax.
> 

I don't know why this would be necessary. It reminds me of all the
variable use variations in Perl that I can never remember "$var, %var,
@var, #var, etc". If ${somevar} is used in an object context, provide
the object unconverted. If it is used in a string context, call the
Object.toString() on it and use that value. If other datatype
conversions are needed, then something like an implicit C++ casting
operator can be implemented by looking for a
DataType.valueOf(<propertyValue>) method.

> In particular, notice that today I can say:
> <classpath refid="${choice}-id" />
> as long as the ids I assigned to my path objects follow a pattern.
> 

I don't think what is being proposed precludes this use at all.

sim

-- 
Mustard Seed Software
mailto:simeon@fitch.net

Mime
View raw message