One of the things I bring up here is why overriding base library behavior is often useful - I thought it might be a good idea to give an example of that, and show how you manage it in VisualWorks.

Here's a a view of the Browser, with a method overridden:

I've shrunken the image for space reasons, but in the top right you'll see that the method is red. That indicates that I've overriden a method owned by a different package (WithStyle, in this case) in the posting tool's package. The override is this snippet of code I added:

	(value isNil or: [value isEmpty])
		ifTrue: [value := ParagraphEditor currentSelection].

In the method above, "value" holds a string that will be the default choice in a dialog box that is popped up for data entry. In this case, it's popped up when the user wants to insert an image into the post. I figured it would be nice if the tool remembered the last image that got uploaded, and made that the default choice. As it happened, the WS method was usually leaving that choice blank (thus, requiring me to type it all in).

I spoke to Michael, and he told me that better pluggability there would be a good thing. In the meantime though, I'm stuck - unless I override. So I did that, and you see the way the browser displays it - in a way that is easy to pick out. I can also version this override off separate from the WS code (thus, not perturbing their codebase). Later, after they've addressed this, I simply remove the override (a menu pick in the browser) and adjust my code to deal with their pluggability.

Simple, and it gets the job done - and in the interim - unlike the situation with Java, or C# - I don't have to either wait for the vendor, or write an entire replacement library/wrapper to get around the limitation. Two lines added to an override, and I'm done.

Of course, some people "don't trust developers", so they are happy wearing the chains the vendors hand them...