On Removing Methods

Bob Arning arning at charm.net
Tue Jun 20 00:47:21 UTC 2000


Hi Karl,

On Tue, 20 Jun 2000 09:21:19 +1000 Karl Goiser <squeak at wattle.net> wrote:
>I've had a brief look at BobsUI v2.  It works under 2.8, but not the 
>2.9 changes, so I had a look and found the following in MenuMorph:
>
>popUpAt: aPoint event: evt
>    "Present this menu at the given point in response to the given event."
>
>    self halt.		"there are currently no senders in image"
>
>
>    "self popUpAt: aPoint forHand: evt hand"
>
>
>I'm not criticising the person who did this - there are no senders in 
>the image unless you have BobsUIv2 installed.

It's interesting that this should come up - I had something to do with the origin of BobsUI and I was the one who put the halt into the method you encountered. I have also recently seen things removed from the image on which some of my out-of-image code depended. Thus I find myself on all sides of the issue. It would be nice if there were a cost-free solution, but I just don't know what it is. For Squeak to grow in interesting new ways, it is almost inevitable that some old things will break. This is one of those cases.

>Is this area problematic or what?

Not so much "problematic" as "in transition". Many of the changes I have recently submitted have been in support of multiple projects being active concurrently. This has interesting implications WRT modularity and squeak as a network medium. The specific change here is that multiple projects imply multiple worlds and in support of that I have started shifting some of the interfaces to a more explicit expression of the world involved. In the case you mentioned, senders of #popUpAt:event: and #popUpAt:forHand: should be migrating toward #popUpAt:forHand:in:.

>Perhaps people could 'register' their use of classes and methods in 
>what is basically the Squeak API and 

That sounds easy until you consider the logistics: 
- how many independent packages?
- how many classes/methods?
- how specific a dependency (simple existence or various levels of functional details)?
- who would maintain this?
- what would be the time (before or after) between notification and change?

>receive notification should 
>there be any changes?  Perhaps it could be done in the local image - 
>a project registers with a particular 'version' of a method?

You can do that now. Every change you file into your image leaves a ChangeRecord which specifies the classes/methods which were added/modified/removed. It wouldn't be a big job to compare those against classes referenced and messages sent from any body of existing code.

>Trouble happens when changes break third-party code you are using. 

Well, yes and no. A couple of things to remember:
- 2.9 is an alpha, test-pilot release at the moment. This suggests the existence of potentially disharmonious changes. Those who want a stable image on which to base third-party development outside the image would do well to select a stable image and work from that.
- Third-party code which is available on the internet *can* go stale. To try to guarantee backward compatibility for everything that has ever been written is too large a task. Providers of such packages can, at least, provide some indication of compatibility levels - e.g. things that I have made available have been designated with a Squeak realease number on my swiki page. Occasionally I hear from someone interested in using older code in a newer image. Sometimes I update the code and sometimes I don't.

>You then have to wait for that code to be updated...

You actually have several choices:
- continue using the code in an image for which it was written
- fix it yourself
- contact the author for a newer version

I keep lots of Squeak images on my system. My email client, e.g. is still running in 2.5 because I haven't completed the transition to a newer version. But it still works there.

>This is just too difficult for my small mind at the moment.

Well, you've actually asked lots of good questions. If my answers aren't up to the task, let me know.

Cheers,
Bob





More information about the Squeak-dev mailing list