The ExtensionHelper module was originally intended as just an interim thing while we were sorting out the SPIs anyway, so if we go ahead with this its fine to move those abstract classes into the SPI module. Just adding something new to the SPI module seems fine to me as its not going to break anything so I'm still +1 on doing this.
...ant On 8/8/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > On 8/8/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I just observed that, not all bindings are extending from > > AbstractBinding though all implement the interface Binding. The > > AbstractBinding class provides an implementation for the Binding > > interface and in my opinion should be used by all bindings to avoid > > duplication of code that implements the BInding interface. > > > > I feel the pinch for this now as I am adding a couple of things for > > policies and seems a bit odd to go an copy over the same things across > > a dozen classes. > > > > Let me know what people feel about this and I can go and fix all the > > bindings for this. > > > > Thanks. > > > > - Venkat > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > I like the idea but it gives me a problem with the sca binding. Adding it > to > SCABinding would imply a cyclic dependency as AbstractBinding is > implemented > in ExtensionHelper (as putting it in the SPI would imply and SPI change I > guess) which in turn depends on quite a lot of other stuff. If we could > separate out AbstractBinding somehow it would work for me. Maybe needs to > wait until our SPI sweep. +1 to using it where ever it can safely be used. > > Simon >
