Howard, would you comment on the deprecated methods that throw an exception ? I understand the value from a documentation point of view (e.g. you have a place in the javadocs that explicitly says which other method is to be used). However, from a code stand point, code that uses those methods will most definitely create a broken app, which seems a bit counter intuitive. In a way, although the change doesn't introduce backward incompatibility at compile time (e.g. your code will still compile) , the end result is that the new changes are NOT backward compatible. I'm not sure if this will end up as a side note in some release notes doc, but I think it would be much more useful to break some builds than to let the builds pass but not behave as expected.
Regards, Alex K On Mon, May 10, 2010 at 12:55 PM, Howard Lewis Ship <[email protected]>wrote: > I wish I had the level of insight into AOP in the context of Tapestry > back in 2005-2006 that I have now. > > On Sun, May 9, 2010 at 6:57 PM, Alex Kotchnev > <[email protected]> wrote: > > Nevermind on the pointers regarding the ClassTransformation API, I think > I > > got it. Once I figured out the couple of classes involved, it was very > > straightforward. > > > > Howard, nice work on the new API, much more readable and cleaner than > > before ! > > I think it will also be easier to debug too, since you'll be able to > set breakpoints inside the various callback objects rather than vainly > seek out dynamically generated code. > > > > > Regards, > > > > Alex Kotchnev > > > > On Sun, May 9, 2010 at 7:36 PM, Alex Kotchnev > > <[email protected]>wrote: > > > >> I've been looking into the new ClassTransformation API and I'm a bit > >> puzzled about why a whole bunch of methods are deprecated and are made > to > >> throw an exception. I guess if any code depends on those methods, it > will > >> compile (w/ deprecation warnings) but will throw up at runtime. So, I'm > a > >> bit puzzled why that's the case. If the intent is to keep just a little > bit > >> of backward compatibility, then it seems likely that the methods > shouldn't > >> throw an exception. If the goal is to replace those methods w/ something > >> else, why not just remove them so any code that depends on them just > doesn't > >> compile. > >> > >> On a separate note, any pointers (beyond the javadoc and Howard's blog > >> posts) on how to replace the old usage w/ the new usage would be highly > >> appreciated. I'll probably dive into 5.2 to see some examples, but > anything > >> extra would be great. > >> > >> Regards, > >> > >> Alex K > >> > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
