On Sun, Jan 10, 2010 at 03:09:10AM +0100, Levente Uzonyi wrote:
> 
> On Sat, 9 Jan 2010, commits at source.squeak.org wrote:
> 
> >David T. Lewis uploaded a new version of Collections to project The Trunk:
> >http://source.squeak.org/trunk/Collections-dtl.276.mcz
> >
> >==================== Summary ====================
> >
> >Name: Collections-dtl.276
> >Author: dtl
> >Time: 9 January 2010, 6:12:34 am
> >UUID: 77fae7af-c5f8-4fe8-b328-680cdd71115f
> >Ancestors: Collections-ar.275
> >
> >Preserve #fullCheck for compatibility with external packages (i.e., 
> >extension methods in Dictionary etc). Important for SystemTracing package 
> >loading.
> >
> 
> Why aren't these methods in the 311Deprecated package?

Good question, and I'm not sure which is better in this case. I think
the choice should be driven by whether we view these as deprecated,
implying that they would be removed perhaps a year or so from now, or
if they are intended as compatability methods that might stay in the
image for a longer period of time.

>From the point of view of an external package maintainer, it is
important for a package to be loadable in a range of images. As a
rule of thumb, I try to provide backward compatibility at least back
to Squeak 3.8. That's a time window of about five years, so I expect
methods intended for compatabily to be available for at least that
long, and I expect deprecated methods to go away after about a year.

As a platform maintainer, my personal pet peeve is the stuff that
got moved into SmalltalkImage, which forced me to write horrible
workarounds in several packages to deal with the "improvement".
For example in OSProcess I have things like this:

  platformName 
    "After Squeak version 3.6, #platformName was moved to SmalltalkImage "
     ^ ((Smalltalk classNamed: 'SmalltalkImage')
         ifNil: [^ Smalltalk platformName]) current platformName

This might seem like a minor complaint, but it is actually very
time consuming to test an external package on a range of images.
I for one do not appreciate being asked to keep up with changes
that provide no functional benefit and waste a lot of my time.

I'm pretty sure that the folks doing e.g. Seaside are going to feel
the same way, so we need to be careful to provide compatibility
methods where appropriate, but not go overboard with it and clutter
up the image with junk. So, to return to the original question,
I'm not sure if these methods should be moved to 311Deprecated,
but if the intent is to keep them for say five years for compatibility,
then no they should not be moved.

Dave