On Tue, 2005-02-15 at 00:23 +0100, Torsten Curdt wrote:
> >>> Yes, I'd like to start committing new Annotation parsing code.
> >>> Problem is,
> >>> of course, is if clients out there were using the Unknown attribute
> >>> to gain
> >>> access to annotations, adding in true Annotation support will cause
> >>> their
> >>> code to fail, as Annotations will no longer be Unknown. Things will
> >>> still
> >>> compile as is, just not run as expected.
> >>>
> >>
> >> Have you considered adding a new method for accessing annotations?
> >>
> >> Code calling the old method would get "Unknown" nodes returned, and new
> >> code would get the real Annotations. And the old method could be marked
> >> as deprecated.
> >>
> >> Regards,
> >>
> >> Simon
> >
> >
> > Yes, we could create Visitor15 interfaces, et. al. But then
>
> *puke* ;)
How about defining a "marker" interface "Visitor15", ie one that has no
methods on it?
Code invoking the visitor interface can then have
if (visitor instanceof Visitor15) {
// pass Attribute
} else {
// pass Unknown
}
Yes, it's a little warty. But it has minimal impact on user code, and
minimal impact on BCEL code.
And if there is a reason to expand the visitor interface later with
additional methods (rather than changing the semantics of the current
API, as this does) then the new interface can define the new API.
The alternative is to move to a BCEL 2.x series. But that means two
branches to maintain, and as is painfully obvious, BCEL doesn't have a
whole lot of developer time available...
BTW, I'm commenting here only from the info in the emails; I haven't yet
had time to actually read the BCEL code + patches. So sorry if I'm not
on the right track here. Anyone know where to get 40 hour days??
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
