ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Bailliez" <>
Subject Re: Speaking of deprecation...
Date Fri, 08 Feb 2002 19:22:36 GMT
----- Original Message -----
From: <>

> Removing a feature from documentation is IMHO even worse than
> removing it from the code - while I can accept that some
> features were 'bad' and shouldn't be supported ( for very
> good reasons, like 'we prefer a different name for this
> attribute' ), they should remain in the documentation
> with the 'deprecated' mark and maybe a justification
> for the reason it was deprecated and who made the decision
> and when.

Should we say 'where' as well ? :-)

> I really _hate_ the 'deprecated' message in ant. Especially when it's

I hate also the deprecated message in the java compiler but it is here to
remind me something.
Fortunately I think I rarely use deprecated methods/class since a
sophisticated IDE usually identify this during auto-completion.

But maybe we can add a -deprecated to Ant to be javac like.

I have seen colleagues of mine using deprecated methods without knowing it
(and with a kind of magnet with using deprecated method)  they didn't even
care until the day I turned on deprecation on all our build files to stop
this abuse, when they first compiled it you should have seen their face
"horror, the code does not compile, I have loads of errors ! What's wrong
?", "you're using deprecated methods, dude, fix this."

> because someone has a different taste and doesn't like the old name.

AFAIK name change that have occurred were justified. The Stroop effect is
well known and is terrible, and most of the changes are there to homogeneize
the whole thing. It has been a user request to be somewhat homogeneous in
the naming because newbies are mostly lost by all the different names
meaning the same thing. You are

Why having "dir", "directory", "dirname" or "tofile", "file", "destfile",
"jarfile", "zipfile", "warfile" when you can standardize in one of them ?
Don't you think it helps to make things more understandable ?

> So I'm -1 on removing deprecated freatures from docs,
> the same as I'm -1 on removing deprecated features without
> a very solid reason ( like that for Thread.stop() ).

> JDK1.4 is still backward compatible with JDK1.1, including
> a lot of stuff that's far worse than 'licence versus license'
> naming preferences. If you have a problem a feature, say -1 when
> it is added or before the release. Or before it is documented.

For that, would you mind adding your +1 about "adding a feature in a nightly
build n does not mean it will be there for nightly build n+1". Thank you.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message