ECMAScript 4

ECMAScript is the standardized form of the language known as JavaScript. In its current incarnation, it is a nice little prototype-based object language that unfortunately is plagued by some warts (peruse this blog post to read about some of them) and by DOM implementation riddled with bugs and security problems. This, according to Douglas Crockford, makes it “the world’s most misunderstood programming language”.

The guys at Ecmascript.org are actively working on a new revision of the standard, and have recently published a new proposal for ECMAScript, edition 4, complete with a reference implementation. This new proposal looks like a 180° turn from the current language, moving to a class-based object orientation paradigm, with multimethods, optional static typing, etc.

The proposal has been well-received by programming-languages researchers and aficionados, such as those at Lambda the Ultimate. But many others, such as Dave “Smalltalk” Thomas, have voiced their opposition to this new standard:

Just browsing through the wiki shows a language which has prototypes, classes, multi-methods?, static types, dynamic types, etc, etc. This reminds an old guy like myself of other large design by committee languages such as PL/I, Algol 68 and ADA. These ambitious efforts all had smart people involved in the design and implementation but were unfortunately far too complex and came to the market too late. JS is intended to be a language for the people, not another language that only technical wizards can understand. If you are an Ajax developer or care about dynamic languages I suggest that it is time for you to speak up and help put ECMAScript 4 on a much less ambitious path than is currently being charted. Less is truly more when it comes to languages.

My friend Riffraff has too a good critique of the proposal:

The second system syndrome is that evil effect that often happens when redesign a small, working system so that it becomes a huge leviathan built by piling new features over new features.

Today I was reading the overview of ECMASCript 4 from ecmascript.org, and I got this very bad feeling that maybe the fourth version of ES, is suffering of an extremely strong case of this problem.*

To make things worse, it looks like there’s some sort of fracture in the ECMAScript 4 working group, with Adobe and Mozilla on one side, and Microsoft and Yahoo! on the other.

In my opiion, all of this doesn’t bode well for the new language. Are we going towards another browser war?

HttpView2 1.1-beta

Yesterday I released a first beta version of HttpView2. This is the first development release of HV2 since Goran published version 1.0 in November 2004.

HttpView2 (aka HV2) is a little, lean web framework for Squeak. Since Goran, the original author, has given me complete development freedom, I’m steering HV2 away from being a framework for web applications and towards being one for RESTful web services.

Highlights of this new development release include:

• a new, generic Canvas system


• a new XHTML Canvas system, inspired by Seaside’s one.


• HTTP responses are now accessible from the various View methods


• source code reorganization

HV2 1.1 is available on Squeak Map. If you have any bug reports, or you’re interested in helping, drop me a line in the comments.

RESTful Web Services Example 3.4 - Obtaining a list of buckets

Example 3.4 of the RESTful Web Services deals with obtaining a list of buckets (think of them as top-leve directories). This first version of the code will return a collection of strings, each one being the name of a single bucket. This is done by sending #getBuckets to an S3BucketList instance.

If you load the latest code (RWS-gc.25) from the RWS repository you’ll see many new changes. The ones we’re interested into are the S3Authorized class and the S3BucketList class.

The former is a class extracted via refactorings from the S3Object class, while the latter allows you to get the list of your buckets.

Take a look at S3BucketList>>getBuckets. The method is defined as:

S3BucketList>>getBuckets
    | doc |
    "Fetch all the buckets this user has defined.

    Code taken from RESTful Web Services. Copyright © 2007 O'Reilly Media, Inc.
    All rights reserved. Used with permission."

    "GET the bucket list URI and build an XML DOM tree from it."
    doc := XMLDOMParser 
            parseDocumentFrom: (self get: Host) contents readStream.
    "For every bucket, collect its name"
    ^ doc // 'Bucket' / 'Name' collect: [:each | each contentString]

As you may see, the Smalltalk code is shorter than the corresponding Ruby code. That’s because we used Pastell, an XPath-like DSL for navigating XML DOM trees, instead of using a separate XPath library.

The first line of code creates a DOM tree from the XML document obtained by sending #get: to itself. #get: is one of the new messages added in the previous post.

In the second line, the DOM tree is sent a #// message. This message selects all the descendant nodes of an XML node whose name matches the argument of the message. In this example, the result of this message send will be a collection of nodes whose tag is 'Bucket'. This collection is a special subclass of OrderedCollection that can understand the Pastell messages, called PastellCollection

The list of nodes is sent another Pastell message, #/. This message selects all the child nodes whose tag matches the argument of the message. In this example, when sent to the PastellCollection instance returned by #//, it returns another PastellCollection whose elements have a 'Name' tag. We can retrieve the actual names of this elements by collect:ing their contentStrings.

In the next two examples, we’ll see how to model a single bucket as a Squeak object, and how to modify S3BucketList>>getBuckets in order to make it return a collection of objects instead of strings.

RESTful Web Services - A Better HTTP interface

Before moving to the remaining Amazon S3 examples from Chapter 3 of the RESTFul Web Services book, let’s take another look at the code. The previous examples were strongly inspired by the corresponding Ruby examples. This, paired with the use of the libCurl bindings, has led to code which is brittle and hard to modify.

As an example, let’s consider the code for S3Object>>open:method:headers:. This method requires the HTTP method in order to compute the correct signature for the request, but then ignores it by sending request download, which is the message used to send a GET request. A possible solution for this is to use a case-like solution in order to send the right message; the code would then become something like this:

(method asLowercase == 'put')
    ifTrue: [request upload]
    ifFalse: [request download]

Now, this isn’t just ugly, it’s plain bad OO code. This means we have to look for another solution.

The solution that I’ve chosen is based on the pattern used for Seaside’s and HV2’s Canvas systems. It involves having an S3Request object that wraps a Curl instance and provides a simple interface. S3Request has different subclasses for the various HTTP methods: S3GetRequest, S3PutRequest etc.

The code for S3Request and its subclasses may be found in package RWS-gc.20 from the RWS repository. S3Request is defined as:

Object subclass: #S3Request
    instanceVariableNames: 'headers url request contents'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'RWS-Examples'

I won’t provide a detailed explaination for this class, save for the #send message:

S3Request>>send
    request := Curl new.
    request url: url.
    headers keysAndValuesDo:
        [:key :value |
        request addHeader: key, ': ', value].
    request onHttpHeaders.
    self perform.
^ request

#send creates a new Curl object, sets the headers and url for the new request, then sends a #perform message to itself before returning the Curl object. #perform is an abstract message implemented by the various subclasses of S3Request. For example, S3PutRequest>>perform looks like

S3PutRequest>>perform
    contents ifNotNil: [request contents: contents].
    request upload

This is a simple and elegant solution to our problem that, while adding 5 new classes to the system, keeps the overall complexity of the code to a much lower level.

In order to use this new API, I’ve added some more messages to the protocols of S3Object. If you browse the latest versions of this class, you’ll find many methods such as #get:headers:, #put:contents:headers: etc. This methods replace the #open:method:headers: message and its variants.

In the next post, we’ll see how to interact with the Amazon S3 service. Meanwhile, I suggest you go over Chapter 3 of Richardson and Ruby’s book in order to get yourself acquainted with S3’s lingo.

KomHttpServer 7.0.5

In the past days I’ve become one of the mantainers of KomHttpServer, Squeak’s native HTTP server. I’ve just released a new version (available on Squeak Map) that includes various bug fixes, and HTTP 1.1 compliant status codes (plus some WebDAV ones, too).

I’d like to thank Goran, Ron, Philippe and all the others for the work they’ve done on Kom’s source code.

Vito Di Modugno Organ Quartet plays Haitian Fight Song

Charles Mingus’ Haitian Fight Song (and its later variant II B.S.) is one of my favourite jazz pieces. And the organ, especially the Hammond organ, is one of my favourite musical instruments. So I was very pleased to find on Youtube a version of Haitian Fight Song played by the Vito di Modugno Organ Quartet. Here is it, for your hearing pleasure:

Miles Davis - So What 1958 & 1964

Looks like I’m not the only one with a blog who’s interested in Jazz and programming. Patrick Logan just published a wonderful post about Miles Davis’ So What So What is a track from the Kind of Blue album, and Patrick compares two different versions of it: the first one from 1958, the second one from 1964. It’s difficult to say which one I prefer.

Incidentally, just ten days ago in the #verbamanent IRC channel we briefly discussed and compared Davis’ Kind of Blue, Coltrane’s A Love Supreme and Mingus’ The Black Saint & The Sinner Lady. The comparision is a little inappropriate, since Kind of Blue precedes the other two albums by roughly five years, but it’s interesting nonetheless. I’m going to write more about these three albums in another post.