Fwd: BankAccount Tutorial

Bob Arning arning at charm.net
Fri Jun 29 15:53:24 UTC 2001


On Fri, 29 Jun 2001 11:13:51 -0400 (EDT) woods at weird.com (Greg A. Woods) wrote:
>[ On Friday, June 29, 2001 at 08:52:58 (-0400), Dan Ingalls wrote: ]
>> Subject: Re: Fwd: BankAccount Tutorial
>> 3.  This did not find anything I hoped for (users of a new centering
>> message), except that it located the wonderfully revealing method,
>> 	convertOldAlignmentsNov2000: varDict using: smartRefStrm
>> which makes it quite clear that the old #centering: message has been
>> replaced by a new #wrapCentering: message.
>This brings up a question I've had about managing change in message
>It's very interesting to see that there are indeed instances of methods
>such as the one you refer to above.
>It seems very good to write such methods and use them to convert
>everything that happens to be in an image at the time, as well as to
>leave them in the system for posterity, but this doesn't do anything for
>code that might be written in older images, saved in changesets or
>projects, etc.

These methods are not there just for posterity. In fact, their primary purpose is to convert old instances that are encountered when loading a project created before the changeover into a more modern image, so they have a definite day-to-day utility. 

As for converting code, it might be possible to do *something*, but I'm not sure how useful it could be without a great deal of work. Sometimes the protocol change is a simple 1-to-1 replacement, using #foo in all cases instead of #fu, e.g. Other changes may not be so simple -- changes to the semantics of #hResizing: and #vResizing: necessitated a careful examination of each sender to determine whether #shrinkWrap or #spaceFill was the appropriate choice going forward. In an even larger view, these same changes mean that any Morph can do the job once done by AlignmentMorph and do it better. This may affect the design of some morphs such that layer(s) of nested morphs required to accomplish a given layout might be replaced with a single, more capable layer. How to search for these in any helpful way would be hard to implement.


>Would it be possible to (also) collect such methods into an enhanced
>"fileIn" that would be able to at least detect old protocols, if not
>actually fix them on the way in?

More information about the Squeak-dev mailing list