ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@ebinteractive.com.au>
Subject RE: Expansion in includes
Date Thu, 07 Dec 2000 07:19:23 GMT
> From: James Duncan Davidson [mailto:duncan@x180.net]
>
>
> On 12/6/00 10:47 PM, "Conor MacNeill" <conor@ebinteractive.com.au> wrote:
>
> > Well we have been debating whether that will continue to be true :-)
>
> I'm -1 on typing them.

If you don't give a (good) reason, I'm afraid I'll have to downgrade that to
a -0 :-) (Seems to be the new rule :-)

>
> 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,

I agree. We can leave them unresolved until reflection time and by then they
should have value. That change should be made. The ordering problem occurs
now as the code tries to resolve them when they are read in, I think.

> 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.
>

Hmmm. We probably have different approaches. I don't know of an occasion
where I use a property to which I haven't given a value. Since the original
ant behaviour, IIRC, was to replace such usage with "null", I can't imagine
many other people did either.

Implicitly giving undefined properties an empty value can bite badly. It has
happened to me and I have seen it happening to users on the ant-user list.
It is hard to debug and IMHO, it is better to fail-fast.

Conor


Mime
View raw message