At some point in the future, it's going to become important to
accurately determine whether a public API is incompatibly changing. This
is a type of subtle, incompatible change to an API that we should all
know about.
Making this type of change in a compatible way depends on having the
parameters that are passed into the interface correctly defined, e.g.,
requiring that the argument be derived from some base class so that when
a new method is added to the base class, it has some reasonable default
behavior rather than raising an exception.
Would you like me to write a program that uses only ImageInterface
(without using ProgressTracker at all) that works before your change but
breaks with a NotImplementedError after the change? Would that convince
you that this really is an incompatible change to ImageInterface?
All I'm looking for is that we acknowledge that this really is an
incompatible change to ImageInterface. We have to acknowledge
incompatible changes if we are to avoid them in the future.
Thanks.
Tom
Shawn Walker wrote:
Tom Mueller wrote:
...
However, I still maintain that this change is an incompatible change
to the ImageInterface interface. (I'm just calling a spade a spade.)
For example, if you had a class:
...
Here, I haven't said anything about what the type of the a object
actually has to be, and with Python, there actually isn't any
requirement that object passed in to __init__ have any particular
type, as long as it implements the right methods.
This is exactly what is happening with the ImageInterface class with
this change. This isn't about whether ProgressTracker is public or
not. It is about what is happening to ImageInterface.
Now if all of ImageInterface isn't considered "public", specifically
the 3rd parameter of the __init__ method, then I stand corrected.
But at this point, I thought that all of ImageInterface was supposed
to be "public".
I think we're just arguing semantics at this time.
All of *ImageInterface* is public, but progresstracker is not part of
ImageInterface.
The main points here are that:
* the public client API has never documented what it expects for a
progresstracker object and has always had a loosely coupled
relationship with it
* changes to the progresstracker object currently do not cause a
change in API version
* changes to the progresstracker object are not documented as they are
for pkg.client.api
* the docstring in the progresstracker class only says that subclasses
must implement all output methods, but doesn't say why or how, or
anything about versioning, etc.
So even if we were to agree that the public client API was
incompatibly changing (which I do not), it doesn't matter as changes
to progresstracker are not currently documented nor considered part of
the public client API.
I realise the argument you're making is that the usage of the tracker
object provided by clients by pkg.client.api is incompatibly changing,
but I can't do anything about that. That's what the new bug I'm
opening to resolve this is about.
I'm not certain what you want me to do here or what the point of all
of this is.
Cheers,
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;SWI Install/Update Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[email protected]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
