> -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Tuesday, June 28, 2016 09:07 > 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 28 June 2016 at 16:52, Dennis E. Hamilton <dennis.hamil...@acm.org> > wrote: > > 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. > > That depends on what you mean by careful. > AFAICT it is only safe if the client only implements the interface > methods and no other protected or public methods. > That is rather restrictive. [orcmid]
I think I don't know what you mean by client. I assume a client is code that relies on an existing class or interface type as offered by an implementation provided by someone else. As the provider of a class, there is more to consider. > > > 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. > > Not sure I understand how that can happen if methods are never dropped > from interfaces. > Seems tangential to the earlier discussion. > > > 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. > > No idea what that means. [orcmid] I mean that there are problems that can arise for developers no matter what ones approach to API maintenance happens to be, so it is not so much about abstract classes and inheritance or interfaces (and inheritance) and various combinations. > > > 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. > > I think it would help if you provided a simple example of what you > mean by interface versions. > For example, how does one add a method to an interface in your scheme? [orcmid] A modification of an interface requires definition of a new type. It might be by inheritance off of an already-defined interface type, but a new type is defined. An implementing class might implement one or both. Methods that accept interfaces as parameters specify the simplest interface parameter type that satisfies requirements for the method. It is handy for clients (users not providers) of an interface to be shielded from assumptions about what the implementing class is. This can be by having interfaces delivered as results from methods that would normally return instances and having the instantiation of specific implementing classes be well-isolated/-encapsulated somewhere. That's a pretty generic observation. The devil is in the details, of course. (Another invariant [;<). I favor the level of discipline that is involved for this. I do not pretend that it serves all purposes. > > > - Dennis > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
