ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: Expansion in includes
Date Thu, 07 Dec 2000 06:47:01 GMT
> From: James Duncan Davidson []
> Typing in commands -- yes it give an error, but in a shell script (even
> /bin/sh) if you say 'echo asdf${barf}asdf', you get 'asdfasdf' -- at least
> on my shell here. :)
> > What you are suggesting is closer to MAKE's behavior, AHHHHHGGGGGGG :-P
> Properties are always just strings -- not of any other type.

Well we have been debating whether that will continue to be true :-)

> An
> empty string
> can be either "" or null. Since there are no other types here, and I can't
> think of a case in using a property where you really care about the
> difference between "" and null, using "" for the undefined just seems
> natural.

Regardless of what the Unix shell may do, we need to preserve the current
behaviour. Ant now allows properties to be read in from properties files.
The order in which property strings are delivered from the Properties object
used to read the file will, in general, be different from the order of the
properties in the file itself. If these properties reference other
properties, we can have, effectively, forward references. These forward
references are left "intact" for later resolution - ie when the referred
property value is delivered from the Properties object.

In general, I don't think we should implicitly interpret undefined
properties as empty strings. If you use a property, you should give it a
value. If the property is not defined, the usage is probably a mistake. I
prefer things to be explicit (TM). As I said, that would be my preference
but the forward reference issue requires that undefined properties are
passed through unchanged, at least for now. The best we can do is log a


View raw message