I have to disagree, if you leave it as an interface and we have current
implementations of it, what happens
if we add some new methods in a future release? All implementations
would have to be updated to reflect
the new APIs, however, if you use an abstract class with default
implementations, then existing extensionhandlers
would not need to be modified. Granted, if you change existing methods
then subtle bugs will appear.
Does anyone else have any thoughts on the subject?
Vivek Pandey wrote:
> This is not a good idea. It can be problematic as future changes in
> the apis wont be easiliy detectable by the superclasses resulting in
> to bugs thats hard to fix.
>
> Moreover it doesn't provide much to the implementor of this class,
> current IDEs can automatically generate the default implementations of
> these methods - I guess thats pretty much the NOOP implementation do.
>
> IMO, we should have this class as interface if not then we should not
> keep the default implementations in it.
>
> -vivek.
>
> Doug Kohlert wrote:
>
>> At the request of a potential implementor of this extension, I made
>> it an abstract class rather than an interface.
>>
>> Doug Kohlert wrote:
>>
>>> I removed all uses of CheckedException from from the
>>> WSDLGeneratorExtension api as it appears that
>>> no component from the wsinterop project needs access to it.
>>>
>>
>
--
- Doug