ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: <available> / <condition> breaking immutability
Date Wed, 28 Nov 2001 08:09:53 GMT
On Wed, 28 Nov 2001 08:04, Bruce Atherton wrote:
> At 06:26 AM 11/28/2001 +1100, Peter Donald wrote:
> > > Either of these solutions will work, but only by adding unnecessary
> > > complexity for the user.
> >
> >god no. Its simplifying for the user. Any programmer who reuses the same
> >variable to mean completely different things ... and thinks it is the
> > "right thing" .... they would be called a fool. Yet you seem to think it
> > is ok for build engineers ...
>
> I think no such thing.
>
> The properties in <tstamp> always stand for the time that tstamp was
> called. How is that "different things"?

Errrrr .... put it this way. If you were writing code which would you think 
is the better approach

------------------------------------------------------
final int start = getTime();
System.out.println( "Start: " + start );
...action
final int end = getTime();
System.out.println( "End: " + end );

... vs ...

int time = getTime();
System.out.println( "Start: " + time );
...action
time = getTime();
System.out.println( "End: " + time );
------------------------------------------------------

If you prefer the first way - why do you see writing build files as being any 
different ?

If you prefer the second way ... well ... what can I say, variable recycling 
is bad software engineering and if you can't see that then ....

> Even for the <available> task which I find a debatable one, consider this
> case. It is obviously artificial but makes a point:
>
>      <available property="file.present" file="file.txt" filepath="mydir" />
>      <!--  ... do stuff ... -->
>      <delete dir="mydir" />
>      <!--  ... do other stuff ... -->
>      <cvs command="co" package="mydir" />
>      <available property="file.present" file="file.txt" filepath="mydir" />
>      <!--  ... WTF? ... -->

Of course when you read that propertys in ant are immutable it would not make 
sense to write a snippet like that.

> Of course there are ways around this, but a build engineer who wrote their
> system that way would not be "a fool".

maybe just someone who doesn't consider software engineering a high priority 
- in which case they deserve anything their hacks get them.

> A task writer's whim could only affect their own custom tasks.

A lot of projects are shipping custom tasks in some form or another. If they 
write crap because we made it easy for them to write crap and it makes ant 
look bad (say some of the tasks end up in wide use) then it is a slightly 
bigger issue ... or would you disagree ?

> Your culture
> here would never let a whim make it into the repository.

wanna bet ? ;) Besides we are still paying for choices made early in ant 
lifecycle - long before any of the current active committers were about.

> >The names of these tasks you just need to
> >memorize and there is no where in recorded documentation that this
> > behaviour should violate the bahevour of standard ant property rules.
>
> Who ever said that? That would indeed be outlandish.

You are saying that as far as I can tell. You say all tasks should behave as 
if propertys were immutable except these ones ....

-- 
Cheers,

Pete

*---------------------------------------------------------*
| Programming today is a race between software engineers  |
| striving to build bigger and better idiot-proof         |
| programs,and the universe trying to produce bigger and  |
| better idiots. So far, the universe is winning.         |
|                       - Richard Cook                    |
*---------------------------------------------------------*

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message