ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: Multiple patternsets in a fileset
Date Mon, 18 Feb 2002 01:32:38 GMT
At 06:57 PM 2/17/02 -0500, Erik Hatcher wrote:
>Just to add more fuel to the fire - even if we were to change this behavior,
>it could not be for Ant 1.x since that would break backwards compatibility.

Now, this is a very good point and a valid reason why one wouldn't want to 
change the current behaviour.

Suppose, though, that Ant 1.x has behaviour that is "incorrect" (as defined 
by the majority of committers). How would people feel about correcting the 
behaviour UNLESS a "-legacy" flag was added to the command line, in which 
case the old behaviour would hold. This is similar to what was discussed 
with BuildExceptions on deprecated features, and would be used in the same 
way. If you had a build file that relied on the old behaviour, you would 
include the flag. Everyone else would get the "correct" behaviour by default.

Since relying on patternsets to behave this way is really an edge case (the 
only reason I can think someone would choose to do it is to get around 
limitations on extending referenced patternsets), it doesn't seem too 
onerous. I would be willing to create a patch for it. Of course all APIs 
would remain backward compatible.

>There are other glaringly difficult issues with other datatypes that cannot
>be resolved in the 1.x codebase.

Would using a "-legacy" flag work for your examples? Or would the APIs have 
to change?

> > Not only is this counterintuitive behaviour for the user, it takes away
> > functionality for no good reason.
>
>Its only counterintuitive if you don't know how a fileset works with
>patternsets.

I don't want this to come off sounding harsh because I really appreciate 
your response and the time it has taken you to write it, but that statement 
is false. Not only that, it is dangerous thinking for a designer.

Intuition is not information. It is how things "appear" to work. The 
behaviour of multiple patternsets is counterintuitive. You may be able to 
overcome that intuitive response once you have enough information from 
digging around in the code, by using the feature all the time, or by 
memorizing the documentation, but that is not what most users will do. 
Users don't read documentation unless it is absolutely necessary. How often 
have you read the documentation on a door ("push" or "pull") only after 
failing to operate it intuitively. When that happens, the fault lies in the 
design of the door, not in you. And as this book 
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0385267746&vm= 
proves time and again, "documenting counterintuitive behaviour = bad, 
fixing counterintuitive behaviour = good".

>I agree that its currently not ideal, but the workaround Conor mentioned
>handles this particular situation relatively painlessly and intuitively, at
>least to me.

The example I gave was really to provide a test case for the bug/design 
decision, not to indicate where my problem lies. My real problem is in the 
APIs and the design of the classes. So no, Conor's workaround does not 
handle this painlessly, much less intuitively. I appreciate him having 
provided it, though. Thanks, Conor.

> > Having separation in patternsets gives you this functionality. Then there
> > is the question of what a user would expect. If you were encountering an
> > ant build.xml file for the first time, would you expect old*.java to be
> > excluded? Honestly?
>
>I know how a fileset works, so yes I would expect that behavior.

"If you were encountering an ant build.xml file for the first time"? Try to 
put yourself into the users' shoes.

>I think your patch would still be a worthy feature to discuss adding even
>given the current way patternsets work.

That's probably a good idea. I can ignore how multiple patternsets interact 
for the time being.

I didn't get the patch finished this weekend, but I hope to get it ready by 
the next. Thanks for the encouragement.



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