John M McIntosh wrote:
>
> Joshua Channing Gargus wrote:
> >
> >There isn't really a full solution to backward changeset
> >compatibility.  For example, I've seen classes which subclass
> >AlignmentMorph and have code like "hResizing _ vResizing _
> >#shrinkWrap" in the "initialize" method.  I don't think it would make
> >sense to leave the inst vars there, as well as code to make them work
> >with the new layout code.
> >
> >I also think that forcing a quick update to the new API makes the
> >system more comprehensible, especially given the current state of
> >documentation.  If I was a new Squeaker, I think I'd be confused by
> >the redundancy.  Let's be honest, I would have been confused anyway!
> 
> Well I think either add back compatibility methods, or a message
> stating what the issue is. Right now you just get a does not
> understand walkback without knowing what the problem is. (well I did
> but you can understand the issue now is that if someone gets a
> current 2.9 image then it's possible that many of the old morphic
> change sets out there won't work for him anymore).

I suppose one compromise might be to add something like "self deprecated" in place of methods which are obsolete/deprecated.  Is there already a convention for this?  (Perhaps the method would also include a comment such as "Removed in the AlignmentMorph work of 11/00.  Use blahblah instead.")

Then, in 2.10alpha (or whatever the next alpha release is), all the methods containing "self deprecated" would be removed.

I'd rather see this than have working backward compatilibity methods littering Squeak at this stage.  (Squeak doesn't have enough legacy apps based on it yet for this to be a big concern, IMHO.)  Of course, adding the deprecated methods in all the right places is a bit of work, too.

- Doug Way
  dway at riskmetrics.com