There are 2 cases to be handled:
1) GoogleCharts and Flotr both want a Color>>#fromString:
method, but they need the method to have different semantics
2) GoogleCharts and Flotr both want a Color>>#fromString:
method with identical semantics
The first case is nearly impossible to handle without renaming one of the method implementations or subclassing Color. However, the second case is easily handled using a technique that I will call optional extension subapplications
. In fact, if you use this technique, you will not need to make any changes to your application if Color>>#fromString:
ever ends up in the base code.
I will use the RBParserApp
from V8.0 as an example. If you want to follow along, open an Application Editions browser and select the RBParserApp
. Notice that this app has one subapp -- RBParserVAApp
. This subapp contains the VA Smalltalk unique code for the parser.
Now switch the browser to the Subapplication Names view and select the RBParserVAApp
. Notice that this subapp has 3 subapps of its own, all with names beginning with RBParserVAStub_
. The remainder of the subapp name relates loosely to the extension method selector (for example, RBParserVAStub_rightArrow
). These subapps contain no code -- they only server to anchor the extension and allow it to be optionally loaded.
Now select the RBParserVAStub_rightArrow
in the Subapplication Names column. Notice that this subapp has just one subapp of its own -- RBParserVA_rightArrow
. This subapp contains just one extension method -- Object>>#->
. All the magic is in the configuration expression for this subapp. The expression is:
- Code: Select all
(Object canUnderstand: #->) not or: [((Object>>#->) application name indexOfSubCollection: 'RB' startingAt: 1) == 1]
So, this subapp is loaded, supplying the extension, only if the extension method is not understood (meaning it does not already exist in the image) or if the extension method is provided by a (sub)app whose name begins with RB (to allow for reloading of the extension).
That's all there is to it -- pretty easy if you know how to do it (I learned this trick from Eric Clayberg many years ago).
John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.