ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: Speaking of deprecation...
Date Sat, 09 Feb 2002 14:31:13 GMT
Talking about replication, is it there a way to find out if a method or class is deprecated
by using reflection?

How do compilers and IDEs find this information out?

Could our Introspection code do the same and provide remove the burden from the code writer?
There are several things that could be achieved this way, for example we could automagically
manage
using attributes with new signatures (and not just assume that String versions are inferior.

In any case, how would one go on doing something like that, I could not find it in Javadoc.

Jose Alberto

----- Original Message ----- 
From: <costinm@covalent.net>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>; "Stephane Bailliez" <sbailliez@apache.org>
Sent: Friday, February 08, 2002 7:53 PM
Subject: Re: Speaking of deprecation...


> 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
> names.
> 
> 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
> maintained.
> 
> 
> 
> Costin
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


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