On Mon, Jan 25, 2010 at 08:47:20PM +0100, Nicolas Cellier wrote:
> 2010/1/25 Juan Vuletich <juan at jvuletich.org>:
> >
> > Hi Folks,
> >
> > (reposted, in the hope of not being ignored)
> >
> > Package developers want their work to run on various Squeak versions and
> > variants, without needing rewrite. Same for app developers.
> >
> > Base image builders want to be free of the need to provide backwards
> > compatibility.
> >
> > This is what I suggest: A package assumes it can use a set of apis of the
> > Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions
> > should be made explicit, in the form of tests. So, for example, for
> > collections, some package developer might require the "Common Collection API
> > tests" to pass. Then, if his package fails to run, let's say in Cuis, he
> > would run the tests for the apis he needs. If some test fails, he could say
> > "Cuis developers, you're not supporting api XXX", end expect them to fix the
> > issue. But if no test fails, he needs to either modify his code so it
> > doesn't use not-standarized apis, or he could negotiate with (all) base
> > image developers the addition of a new api or use case to the test suite and
> > the base images.
> >
> > Building these suites is quite some work, mostly to be done by package
> > developers. But it can easily point out responsibilities and duties. It
> > frees package developers of needing to have a deep knowledge of various base
> > images. And it frees base image developers from needing to know details
> > about an unbounded set of external packages. Besides, it puts popular
> > packages that everybody wants to support on equal footing with less-known
> > packages. It also lets base image developers say "we support Common APIs
> > xxx, yyy, zzz, etc.".
> >
> > All what I say about base images could also apply to packages that offer
> > services to other packages: There could also be test suites to specify their
> > services, and allow users to switch versions of the packages they use
> > knowing what to expect.
> >
> > What do you think?
> >
> > Cheers,
> > Juan Vuletich
> >
> >
> 
> A quick-cheap analysis could be performed:
> - list of classes extended by your packages
> - list of classes subclassed by your packages
> - list of methods used but not implemented by your packages
> With type inference (Roel or other), could be possible to get more
> 
> could lead to tests like:
>   self assertHasClassNamed: #Array.
>   self assertClassNamed: #Array canUnderstand: #collect:. "If you can
> infer type"
>   self assertHasMessage: #at:put:. "if you cannot..."
> etc...
> Doesn't that exists ?
> 
> Of course, it should operate on a Set of packages...

I like Juan's idea a lot, but I lost some enthusiasm when I got to the
part about it being a lot of work ;-)

Maybe by starting with the "quick-cheap" analysis that Nicolas suggests,
it might be manageable.

I think that it would be important that the work be done in small chunks
that can be contributed easily. We need to consider who is doing the work,
and why they would be motivated to spend time on it. For example, the
OSProcess package that I maintain (and I don't know if this is a good
example) already has a large set of unit tests that fail right away if
an expected interface changes. I would be willing to put some work into
writing new tests that document just the api expectations alone, but I
would not want to sink a large amount of time into it because it's
likely to be boring work that does not provide much additional benefit
to me.

So I like the idea, but let's keep it as simple and easy as possible.

Dave