ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Speaking of deprecation...
Date Fri, 08 Feb 2002 19:53:57 GMT
On Fri, 8 Feb 2002, Stephane Bailliez wrote:

> > 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 ? :-)

That would be a good things too :-)

But at least the reason would be a great resource for
users and potential contributors since would avoid
repeating the same mistake.

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

Or a different perspective - I do use deprecated methods and classes all
the time, knowing it. It is a requirement for tomcat3.x to work with
jdk1.1 ( I think for ant too ), it is a requirement for tomcat4.x to
work with jdk1.2 - yet I use JDK1.3, and many things are deprecated.

It is nothing wrong with using deprecated features.

Same for ant - I prefer to write an ant file that works with
many versions of ant, instead of requiring everyone to upgrade
to the latest. That means I have to use features that are
considered deprecated - and I think I'm doing the right thing.

There's a difference between using Thread.stop() or
a feature that may crash my system and using a method with a
name that sounds 'better', or use subelement instead of an
attribute because it looks better.

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

Having a 'homogeneous' structure is good, having the 'nice' attributes
marked as 'prefered' in the docs is also good.

But breaking backward compatibility and displaying warnings when someone
uses "dir" instead of "directory" is very wrong and unjustified.

You can standardize on a naming convention for new tasks, and make sure
old tasks support the same convention - but without removing the old

What would have happened if W3C decided to use a different,
more 'homogenous' naming style for HTML every 6 months ? And what
will happen in 2 years, whith a different set of active commiters
having a different 'taste' for names ?

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

I would go even further and say 'it is ok to remove or change any
feature that is not documented', at least for the tasks and
attribute names.

For the XML reader behavior - that's not completely documented,
but it should - and that should remain cast in stone. That
would allow a refactoring of ProjectHelper, maybe adding
namespaces, etc - as long as the documented behavior is


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

View raw message