GLASS workshop

Cool... this place is offering a week-long workshop on Seaside with GLASS. The page is a bit confusing and light on details but it's cool that this kind of thing is being offered.

The Year of Seaside?

I'm a few weeks late, but I just finished listening to James Robertson and Michael Lukas Smith doing the year in review on the Industry Misinterpretations podcast. I was amused to hear them use the phrase "the year of Seaside" (a reference to Randal Schwartz's predication for Smalltalk this year). There did seem to be a lot of Seaside-related news.

But now that 2008 is over, was it the year of Smalltalk (or Seaside)? Sure, there's a lot of Smalltalk code being written, but that's been true for as long as I've been involved in the community. We made some progress with Gartner; attendance at Smalltalk conferences was high (though it sounds like there are fears it could be low again next year); Randal's predication generated a buzz in the community; and certainly there has been a notable effort to generate publicity outside the community. But is it working?

Have people seen an increase in the size of the community? An increase in Smalltalk-related business? What are our metrics? Was 2008 The Year of Smalltalk?

The Socratic Method

While cleaning out my browser's bookmarks (yes, I'm obsessive enough to do this once and a while), I stumbled across an article I had read by Rick Garlikov about teaching children using the Socratic Method. The Socratic Method, used extensively in the portrayal of Socrates in Plato's writings, is a form of philosophical exploration using questions to stimulate discussion and insight.

In this context, Garlikov is attempting to teach a third grade class about binary arithmetic by asking only questions and allowing the children to work out the answers themselves. A major part of the article is a transcript of this class, which lasted only 25 minutes and apparently resulted in 19 out of 22 students having "fully and excitedly participated and absorbed the entire material".

The article is a quick and inspiring read and I suggest you take a look. I sometimes think it would be nice to volunteer to work with a group of school children (eToys maybe?) and this would be an interesting approach to play with.

There is also a letter to his daughter with further details on Plato and the Socratic Method. If you are at all interested in pedagogy or philosophy, you might also want to check out some of his other articles. I seem to recall finding the article about mistakes made when teaching math interesting.

First Sprint of 2009

This weekend, we completed another very successful Seaside sprint here in Konstanz. We polished off all but a few of our targeted issues and made real progress towards the next alpha release.

Among other things, we added the ability to configure the new session cache, removed our dependency on MessageSend, standardized on the ANSI exception handling protocol and made sure we were signaling meaningful errors.

We also got a shiny new Control Panel implemented in OmniBrowser (see image to the right). There will be more features coming in this area.

Lukas was cleaning up the FileLibrary code on the train on the way here but lost most of it when his image suddenly crashed and ended up only 4MB in size.

I still need to look at some package dependency issues and Philippe and Lukas are working on the ability to add cookies during the callback phase and related bugs.

All in all, a very productive two days!

Object Initialization

Making sure your Smalltalk objects are initialized once and only once can be tricky.

(if you'd rather skip the discussion and go straight to the details, here are Seaside's object initialization conventions)

For starters, some Smalltalks implement #new on Object to call #initialize and some don't. But it gets more complicated than that. For example:

• What should you call a new parameterized initialization method?
• How should a subclass with one of those make sure its superclass is initialized?
• How should class-side instance creation methods work?
• How do you make sure inherited instance creation methods don't result in partially initialized objects?
• What if someone else has made subclasses of yours and is already overriding your superclass' initialization method?

These are just a handful of the possible issues.

For much of the code you write, you can probably avoid worrying about this too much. You were probably using and testing the code as you wrote it, so you know it works. You probably don't have that many levels of subclasses and you (or at least someone on your team) probably knows (or can trace) all the users and subclasses of each class. In many cases, it probably isn't even the end of the world if an object is initialized twice and you're bound to notice pretty quickly if an object is never initialized. All this breaks down as your project and team get bigger, of course.

As a framework, though, I believe Seaside needs to hold its developers to the very highest possible standards of code quality. Seaside is used in Smalltalk images of various platforms all over the world and there is no way that any developer will ever be aware of all the subclasses and users that are out there. Some of our users will implement classes where it does matter if they're initialized twice and when it breaks it will be them not us who notices the problem. This means that we need to be unambiguous, clear, concise, consistent, and portable (and yes, documented... sigh), as well as vigilant in thinking about how developers will subclass, extend, and use our code.

For Seaside, Avi and I worked out a loose convention for this from day one and it has been fairly consistently applied. Some recent discussion on the mailing list, however, has prompted me to formalize and document our conventions. Our requirements are something like:

1. Each object must be initialized once and only once.
2. During initialization, all initialization methods must be called in a predictable order. If my subclass has already overridden my superclass' initialization method, it should still be called. (This means a method should never call super with a selector other than its own).
3. All inherited instance creation methods must result in a completely initialized object.
4. The conventions must be consistently applicable in all cases.
5. It should be very clear to users of the class what parameters are required for initialization.
6. It is more important to minimize the complexity and effort for users of the framework than for developers of the framework.
7. Without sacrificing the above points, we should not have to write or override more code than necessary (we don't want to have to override every instance creation method each time we subclass, for example).

So here are the conventions we use in Seaside. Let me know what you think.