On 12/6/00 10:47 PM, "Conor MacNeill" <[EMAIL PROTECTED]> wrote:
> Well we have been debating whether that will continue to be true :-)
I'm -1 on typing them.
> 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.
And Properties objects are String only -- no typing. And since they are
hashed and properties that have refs to other properties ought to be
resolved at reflection time, there there isn't a problem with ordering --
except in the case where a property refers to a property that refers to the
first. In that case, things are pretty much a toss (and that's about the
only thing that should be an error).
> 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
> warning.
I disagree. In a typical build, I may have dozens of properties that are
perfectly ok to leave empty. I don't think its acceptable to make somebody
go and put in a lot of empty definitions. Would I do this if Ant was its own
fully typed and functional language -- no. But it's not.
--
James Duncan Davidson [EMAIL PROTECTED]
!try; do()
