2010/1/25 Juan Vuletich <juan at jvuletich.org>:
> keith wrote:
>>>>
>>>> This is what happened in the case of ifNotNil: ifNotNilDo: merger.
>>>
>>>
>>> I'm not sure what you're referring to.  The old method still exists, so
>>> no packages that you load can break from it.  What am I missing?
>>
>> A new package that does not know that ifNotNil: [ :value | ] is invalid in
>> 3.8 will not load or compile in 3.8. So you promote compatibility and the
>> ability to migrate, by fixing the OLD image, and migrating the code to the
>> new API there.
>>
>> The advantage of this being that your code base can move forward in situ,
>> and your packages dont have to use the old api, and you can maintain one
>> codebase for all squeak images ever.
>>
>>> You were probably just unaware that #ifNotNilDo: still existed.
>>
>> I know it still exists.
>>
>> Keith
>
> 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...

Nicolas