Where is that Method Defined?
Sometimes you look at a method's declared location and wonder. Take this method in class Text (VisualWorks), for example:
allItalic "Set the emphasis for all characters in the receiver to be italic." self emphasizeAllWith: #italic
Looks like a generic method that should be part of the core aspect of class Text, right? Well, it's not - it's located in package Debugger-Support. This cropped up on us this week, due to the way we do builds now. Instead of RTP stripping, our tool just yanks packages - including Debugger-Support. Whoops. The solution I came up with was to clone the method with a new name in one of our own packages, and change the references in our code (thankfully, only one) to use the new method. This looks like something Cincom should clean up though...
Comments
Re: Where is that Method Defined?
[Troy Brumley] 12 April 2011 11:46:33 AM
Packages are a double edged sword, IMO. They create multiple versions of the truth and, to me, seem to go against the whole OO philosophy of Smalltalk.
Re: Where is that Method Defined?
[anonymous] 12 April 2011 2:28:51 PM
Did the prereq tool not point out the dependency?
Re: Where is that Method Defined?
[James Robertson] 12 April 2011 3:07:16 PM
We are using VW 7.6 here, so you have to make a positive effort to get pre-reqs to show. Even if it had been spotted though, the method is in the wrong place :)
As to Troy's comment, you need to create versionable artifacts somehow....
Re: Where is that Method Defined?
[ Terry] 12 April 2011 4:58:39 PM
Comment by Terry
I make it a point to not use utility methods defined by 3rd party packages. In this situation I think Cincom should have moved the method to the appropriate base package.
With regard to your stripper, I have a stripper I built in 7.3. It strips by removing packages and namespaces. however there are a few classes and methods that must be moved to a different package.