2008/6/16 Sian January <[EMAIL PROTECTED]>: > Is there also a backwards compatability issue with implementors of Visitor > needing to add some new methods? > > > On 13/06/2008, Dave Brosius <[EMAIL PROTECTED]> wrote: >> >> A potential open issue is that existing user code might be expecting to >> process 'unknown' attributes, that are now coming in as first class >> annotations. Therefore that client code will fail until changes are made. I >> meant to look into this, to see if this was indeed true but haven't gotten >> to it yet. As long as we document this, i guess it's ok, although maybe >> folks will be surprised about this change in a point release, i don't know. >> >> --dave
I think that there has to be some scope for some API changes that will break existing code, especially when the visitor pattern has been applied. In my (limited) experience, most clients extend EmptyVisitor -- hence they should be protected from the additional method(s) on Visitor. I can't really see any other way, apart from doing the same thing that Sun did with LayoutManager and LayoutManager2 (ouch). In that case, we'd have to have the Visitor interface as it is now, and then have a Visitor2 (or something like that) interface. I can't see that being a maintainable path. If a client cannot change the code that uses BCEL, then it would make sense for that client to stay with v5.2. On a different topic, I've found an issue with MethodGen. I've raised it as bug #45217. Apologies for the missing description: something very strange happened as I was typing the summary and description, and somehow I managed to raise a blank bug report with the summary "L" :-/ I've updated the summary and added a comment that gives the description. Kind regards, Matthew --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
