On Aug 17, 2011, at 2:40 34PM, Lukas Renggli wrote: >>>> How would that help anybody to find out whether they are relying on >>>> deprecated methods? This seems like a big step backwards form a user >>>> point of view. Suddenly a method is gone and you didn't get a warning. >>>> You are you supposed to check for deprecated methods? Debug each and >>>> every one of your message sends? >>> >>> +1, such an annotation is totally counterproductive. >> >> Provide an alternative. >> Imagine that we're want to deprecate Array>>at: > > Disable the deprecateded notifications in the system settings. Like > this you acknoledge that you use outdated code; and if this gets too > annoying you might want to actually fix it. > > Ideally the deprecated notification debugger could allow you to > disable further warnings. However deprecated warnings should always be > turned on in downloaded images, otherwise we can as well remove them. > > Lukas
+1000 to what Lukas and Phillippe are saying. Always show deprecation warnings for a call site at least once. The whole point of deprecations vanishes if you are not made aware of them at all... If the deprecated method stored callsites in some dictionary, then skipped raising debuggers if already in the dict, that'd be swell. Didn't Alain Plaintec already make a nice GUI for browsing such triggered deprecations, or am I imagining things? IE. I think tool support is much better than a pragma. In fact, for deprecating commonly used methods I feel it is crucial. Until present, may I suggest just not deprecating such methods? I don't see any other way that will not inevitably lead to lots of swearing by users. Cheers, Henry
