Smalltalk SCMs

There are a lot of tools out there to do SCM for file based languages but Smalltalk SCMs have one advantage and that is that the scope of what needs to be compared in much more focused. In Smalltalk the unit of compilation is not a file but rather the method , that includes the class definition which is in reality a method call. So when you browse history you can just immediately scan across time what has occurred for that method. The Smalltalk IDE’s operate  on method objects , compiling its at this level and changes to those methods are are tracked for eventual publication to the SCM which stores said changes at the method level.  Of course methods changes are associated to classes which are associated to packages etc., so one can as easily understand what has changed with a class or package.

Ruby has a great runtime model but unlike Smalltalk the IDE’s available do not live in a Ruby runtime. If they did I think IDE makers would possibly think about exploiting incremental level method compilation which in turn would promote the persisting of changes at the method level and thus much easier tracking of code versioning.

extending others

In Smalltalk its normal to add behavior to third party and kernel classes if said behavior feels “natural” to said class. That’s one of the reasons why you won’t find classes like StringUtils in Smalltalk. Instead if a behavior is something that a String should do well that’s where it goes.

I’m reminded of this because recently I was working on a task where I need to use “zipping” in Ruby. I naturally went to RubyGems which is my default stop to look for Ruby “goodies” where I found the gem rubyzip. Scanning thru the api I could not find something where I could just stipulate the path to a zip file and consequently ask it to extract itself to a destination path. i.e.


file = ZipFile.open 'myzip.zip'

file.extract_to '/home/charles/extracts'

Unfortunately , the exact api wasn’t quite there. I Googled and found folks complaining about the same thing. I also found somebody that actually provided the implementation that achieved the objectives which was fine except for where it was implemented.
The code I found was this:

def extract_archive (file, destination)

Zip::ZipFile.open(file) { |zip_file|
 zip_file.each { |f|
 f_path=File.join(destination, f.name)
 FileUtils.mkdir_p(File.dirname(f_path))
 zip_file.extract(f, f_path)
 }
 }
end

That rubs the Smalltalker in me the wrong way and actually I’m sure it bothers the experienced Ruby developer as well. Ruby like Smalltalk has been built around a culture of thinking of objects and messages but many that come from C and Java backgrounds are just not used to thinking that way.
Ruby has a very nice and simple way of providing for class extensions. All you have to do is simply re-state the class definition and add the methods you want to extend the class with. I therefore created an extension ruby file I called ZipFileExtensions.rb which goes like this:

class Zip::ZipFile

#Instance Side Methods

def extract_to destination

self.each { |f|
 f_path=File.join(destination, f.name)
 FileUtils.mkdir_p(File.dirname(f_path))
 extract(f, f_path)
 }

end

end

This allows me to simply ask a zip_file extract_to destination.
Just like God intended.

Method Visibility

I have to admit that Ruby got this one just right enough. Enough because some implementations like Java’s are just too painful. On the other hand Smalltalk I have always felt was on the other extreme too lenient. In Smalltalk all methods are public and thus visible and consequently can be called at any time. There is no effective distinction between public api and private methods internal to the implementation servicing the public api. So a Smalltalk object is indeed a white box which can lead to abuse.

Ruby got public and private right. Public methods are as implied visible to all. Private methods are indeed totally private to the object. The implementation of “private” is achieved by imposing that private methods cannot have an explicit receiver i.e. you can’t even do  self.my_private_method you have to just use the implicit self i.e. my_private_method.  I can live with that. I’m glad private methods are enforced.

Ruby also has the notion of “protected” methods. Protected methods are visible to members of a class hierarchy. So objects of the same class or ancestry can call each other’s privates (private to the family aka protected) enabling family collaboration.

I should note that method invocation gets past all of this but again in the case of Smalltalk there’s no access distinction so the Rubyist in me is happy.

To be complete I’ll update this article with some code samples although there’s plenty of literature out there so maybe not.

My First Post

I have been coding in Smalltalk since 1994 and I have been very fortunate that it has been full time and for pay. It still pays my bills but I have to admit the Ruby is becoming imminent in my destiny. So now is when I notice? No, I have been playing with Ruby for a quite while and I have been keeping my eye on it, but living in a niche causes me anxiety. If you are a Smalltalker you will know what I mean. Smalltalk is a beautiful thing and it takes a lot to steal a glance away from it. For me at least Ruby is achieving a critical mass, a combination of the language features those beautiful “gems” and a very energetic community and even the IDE’s compel me to get off the sidelines and get involved beyond just know how

This blog will then be about that struggle to embrace Ruby and knowing that it means letting go, its about embracing my birthstone and thus ensure that it is my destiny.