From: "David Megginson" <david@...>
> > * Meta-1: Naming convention for extended versions of
> > current interfaces. I used a numeric suffix; easy to apply
> > everywhere. Does some other convention work better?
> A while ago, someone suggested a different possibility -- modify the
> existing interfaces (as long as the changes are backwards-compatible)
> and include a static version variable in each interface. I don't know
> if that approach has since fallen out of favour in the Java world.
The problem with adding to existing interfaces is that it's only
supposed to be done in cases where "you" control all the
implementations, because otherwise significant backward
compatibility problems come up.
Example: app compiles against "enhanced" interfaces, needs
to run against "original" version. It calls a new method (or
accesses a new static interface member constant) ... runtime
error, of a sort that few developers ever see. Using a "v2"
interface, that would show up as a type checking error during
a cast, which is familiar
Or the other way: "original" impl runs in an environment
with "enhanced" interfaces. Different JVMs have handled
that in different ways ... including instantiation errors. Apps
can't deal with all the failure modes, but they could if V2
interfaces had different names from V1 interfaces.
> > * Meta-2: Implementation classes. New ones, or extend
> > the ones in org.xml.sax.helpers.* ... that's as optional as
> > the org.xml.sax.ext.* stuff, but there's been no coupling yet.
> > I proposed new classes (no coupling), but might prefer
> > the simpler approach.
> I think it's a good idea to avoid coupling.
That's certainly the direction that's been set, and that's why I
wrote it up that way. But it does cause there to be a need for
extra classes, which wouldn't otherwise be necessary. Seemed
worth raising the point, though.