Howard, I guess this was my point exactly : it seems to me "deprecated" code is one that still works (maybe not perfectly ), but is not recommended for future usage. If the "old" methods have no way to reasonably to continue to work (e.g. possibly w/ the old behavior), then in my opinion they should be removed, instead of being marked as deprecated. I'm not advocating to try to reconstruct the old methods and try to make them work in a weird way, despite the fact that the 5.2 design has moved on.
I guess the question is which approach is more useful: to have an explanatory exception at runtime if someone was mixing pre-5.2 and 5.2 compiled code vs pre-5.2 code being more upfront about the incompatibilities at compile time. I'd personally prefer not having the old methods around. Regards, Alex K On Mon, May 10, 2010 at 4:30 PM, Howard Lewis Ship <[email protected]> wrote: > It just comes down to the inability of the old and new methods for > instrumenting component classes to work together. If I could find a > way to make the old code work correctly alongside the new code, I > would. To be honest, I don't remember perfectly what the problems > were, I think it was ambiguities in terms of where fields referenced > inside added methods (added with Javassist pseudo-Java) were > intercepted or not. There may also have been some conflicts in terms > of creating a method (from psuedo-Java) and then adding advice to the > method. > > My goal here was to ensure that if some code relied on the old code, > it would get a useful runtime exception, rather than one of those > wierd incompatible class exceptions (i.e., where the method signature > does not exist). > > On Mon, May 10, 2010 at 11:49 AM, Alex Kotchnev > <[email protected]> wrote: > > 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] > >> > >> > > > > > > -- > 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] > >
