Sebb, although this discussion does not apply to the Commons Crypto API structure, I want to clean one part up.
> -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Monday, June 20, 2016 09:26 > To: Commons Developers List <dev@commons.apache.org>; Dennis Hamilton > <dennis.hamil...@acm.org> > Subject: Re: [CRYPTO] Defining the public API; are its interfaces > supposed to be implemented or just used? > > On 20 June 2016 at 16:48, Dennis E. Hamilton <dennis.hamil...@acm.org> > wrote: [ ... ] > >> > [Interface use] also does not compel all implementations being off the > >> > same > >> [abstract] base class. > >> > >> That much is true. > > [orcmid] > > > > In my application of interfaces, interfaces are (effectively) > versioned. Subsequent releases don't alter existing interface > declarations. That's the whole point. > > OK, in that case yes, but I did not read your original statement that > way. > > > If there is another interface (even based on the original one) that > defines an additional method, only classes that have the interface- > complying methods deliver the new interface. Ones that have a method of > the same name that is not an implementation for the extended interface > do not expose the extended version of the interface. > > > > What am I missing? > > Introducing a new interface is one way to deal with API evolution. > However it forces client code to be editted and recompiled in order to > get the new API. > And if the client code already has a clashing method name, it will > still require additional client code changes. > > Whereas if the interface is never implemented by client code, > additional methods cannot cause problems for client code. [orcmid] If the original interface is correctly implemented by a class, there is never a problem for clients relying on that interface. If another version of the interface, even one based on the original interface, would conflict with a method of some class that implements the original interface, then it is not appropriate to claim implementation of the new version for that class. Its implementation of the original interface remains valid. That is, name collisions are always possible, but they are not so likely to be the result of accidental overloading, assuming those who declare that their class implements an interface are careful. With regard to client code that relies on an interface, the code that relies on the original interface should still find it implemented where it was before and if that becomes unavailable where it was available before, that will become apparent and dramatically visible. So, yes, there are always prospects of name-collision issues over time, depending on how one depends on an interface, changes the interfaces that are implemented by a class, and by whatever one depends on from a super-class/interface in deriving another. I think now we are talking about difficulties that are invariant. For me, relying on interfaces exposes clashes better and places their resolution on those who provide classes that implement interfaces. It is about aligning conventions to keep things as safe against accidental overloading or whatever as possible. I'm having difficulty seeing how a client that relies on an interface from an instance can mess this up, so long as the specific interface type remains supported by the class that defines the instance. (I understand that interfaces are not actually "there" in the runtime binding but that doesn't matter so long as the client code doesn't break the tacit contract by exploiting that.) In any case, I am not proposing any changes at Commons-Crypto. I am interested in understanding better the rejection of interfaces as *an* effective option for API development and management over time. - Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
