Grease Extensions for VA Smalltalk

If you’ve ever tried to use open source code from Squeak or Pharo on VA Smalltalk, you had a few obstacles to take:

How do I load Monticello Packages into my envy library? Many moons ago, you had to use FileIn/FileOut and some manual editing of the fileout to make it loadable. Sometimes, I just gave up on that and copy/pasted code method by method. Nowerdays there is the Montocello Importer from Instantiations, which works very well for importing code from Pharo/Squeak into VAST.
Side note: Unfortunately, there is no solution yet for contributing back to the original projects. In order to do so, you have to work in Pharo – that is really a pity, because in the end we VAST users will look and behave like shameless harvesters who are good at taking code but don’t give back.

Pharo code today is stuffed with method sends for little helper methods on Collections, Strings, Classes and Behavior that make code much cleaner and shorter. These methods are often just re-namings of standard methods, but for special uses. If you need an example: Pharo has this nice #beginsWith: which tests if a String (or SequencableCollection) starts with some String (‘My home is my Castle’ beginsWith: ‘My’). In VAST, there is no such method, but you can achieve the same thing by sending #indexOfSubCollection:startingAt: and test the result whether it is greater than zero. In the end, #beginsWith: just does exactly that, but it is much easier and less error prone to just type beginsWith: than a full test. That is why Pharo code has so many sends to such methods

If you encounter such a method send in to-be-ported-code and want to port it over to VAST, you have two options:

Replace every method send from VAST with a send to “the real thing”

Add the helper methods to VAST

The first alternative has a lot of drawbacks, the most important ones being that you’d have to repeat this every time you port a new version of the code to VAST. If you find a bug in the code, you can hardly communicate about it, because you don’t really use the same code any more. Once there is a solution to contribute fixes and changes back to Pharo (I hope one day there will be such a thing), this also means you’d contribute a version that has all those little easier method sends replaced with more complex ones…

The second one also is not without problems, but more from the perspective of Code Configuration Management and the way Envy works (from a conceptual standpoint). There is a thread on the VAST mailing list that highlights some of the problems this approach has.

Nevertheless, I just started a new mini-project to attack the issue. While porting the Twitter Boostrap code from Pharo to VAST, I just added the methods I needed and put them into a new Application named GreaseVAST860Extensions. I tested if it loads into VAST 8.6.1 as well.

The idea here is that whenever I or other people port code from Pharo and find they need another helper method to make life easier, they can extend my mini-collection of compatibility methods and upload it to VASTGoodies.

I hope this will help us VAST users keep up with the rest of the Smalltalk world. I remember giving up porting newer versions of NeoCSV to VAST because I constantly had to change methods (I tried approach 1 back then, because I had too much respect of the problems Approach 2 would be associated with).

So I want to encourage everybody who uses Pharo code in VAST to use and extend GreaseVASTExtensions and publish their changes back to VASTGoodies.

I think this will make life easier for many of us VAST users.

There are two main areas which remain to make life even better, that I think need to be addressed in the near future:

We urgently need to work on ways to make this one-way-street for code a real street where code can travel both ways. There is a bunch of good open source code on VAST that could be helpful for Pharo users, and we could help improve projects that live in the Pharo eco-system with our contributions or fixes

One thing that Pharoers really like to do is create collections using curly braces. Especially in test methods where you need a bunch of data points to feed into some algorithm, people tend to use {1 10 15 25 $c} rather than OrderedCollection with:with:with: and so on. The {} notation for creating literal arrays is not available in VAST, and so we still have to modify code in order to make it workable in VAST.

Please feel free to download the GreaseVASTExtensions and extend them. Tell me about problems, publish extensions to it and help make VAST an even more beautiful place to work in. Let’s work on ways to improve the manageability and version compliance of this little extension for newer versions of VAST.