 |
|||||||||
|
Smalltalk Solutions 98 Conference — Sessions |
|
I can only comment on the sessions I attended. I will give a brief overview of each session with a few personal comments. I attended two Monday pre-conference sessions, but none on the preceding Sunday afternoon. The detail
in the section below shows my biass and my state of mental tiredness
as the conference progressed. 4.1 M2 Creating Design Patterns in Smalltalk (Bobby Woolf & Kyle Brown) This was not just an advertisement for their new book The Design Patterns Smalltalk Companion (seriously, it wasn't), but having mentioned it, this book attempts to take the book Design Patterns, but "the gang of four" and bring it into the Smalltalk world. It does not replace the book, but as it says, it is a "Companion" book. This session brought patterns home to me. Prior to this I had read the original Design Patterns book and said "so, don't all programmers do this?". The examples, taken from the Smalltalk world, made the patterns more real. Some items taken from the text of the session:
A pattern I noted and will discuss briefly is the "null object" pattern. This is an object which can be substituted for a real object but which does nothing. Let me provide an example and discuss two implementations, mine and their's: We use dates probably more than any other "domain attribute" other than string. It is often the case that the user leaves a date blank, and we interpret this as a "null date". We have a subclass of "Date" which, among other things, contains a "null" flag (a boolean instance variable). A number of methods must test for null and do something (or more likely nothing). This pattern repeats in a number of other classes (subclass of Time, DateTime). Their implementation would define a NullDate class, and an instance of NullDate would react correctly to the various messages which might be sent to date (correctly for a null date). This could be built as a separate class or as a subclass of Date. This is a better and simpler pattern than the one which implements a boolean instance variable. Having seen this once, that is now the way I would always do it. Conclusions?
4.2 M5 Understanding Transparency in Distributed Systems (Martin McClure) Martin McClure is from Gemstone, and this presentation, although general in nature, took many of its examples from Gemstone (not unexpected, nor unreasonable). First, I did not know from the title what this session would be about. It was only the abstract which drew me to it. To summarize, transparency in this context means the ability to access an object on a remote system as if it were local. How many ways can one do this - certainly more ways than I would have been able to list. Transparency in Smalltalk is much easier than in other languages (e.g. C++) because of the total encapsulation of data. It was interesting to see the whole problem documented. Its not just "get a message to that remote object". You have to:
The problem is perhaps not quite as simple as it may have appeared at first statement. If anyone has worked with Gemstone/Gembuilder (or Distributed Smalltalk) they will likely have seen some of this in action. Some of the mechanisms used for transparency:
I think this could have been an interesting topic, and there was some interesting information, although I, personally, considered some of it a bit basic. I and a few others felt that the session was overshadowed somewhat by the remarks in the next paragraph. The speaker began by prohibiting any changes to base classes (Object, Collection, ...). The general feeling was that the absolute prohibition was a bit much and rather limiting. Sure, putting a method in Object because its "convenient" is no answer, but adding a method to Object so it can be overridden in many other classes is what Smalltalk is all about. Smalltalk is not slow was a key point, but don't use it for things it is not intended for. For example, don't code an FFT (Fast Fourier Transform) in Smalltalk (or Java or C++), use an optimizing Fortran Compiler. For manipulating Objects, Smalltalk rivals C++. Don't look at your code to optimize, use a profiler. The slow spots are never where you think they are. This of course applies to any language, and anyone who has ever profiled and optimized knows that. Benchmarking (so you can see when changes occur), and Profiling to find the weak spots are the key to optimal applications. Profilers available:
4.3 T6 Designing and Building Server Objects (Jay Almarode) Jay Almarode is, of course, from Gemstone, and this talk related directly to Gemstone. It turned out to be more applicable to my own work than I had expected and provided some very useful direction. Topics covered included:
Discussion centred around project and team management issues.
I saw this as an advanced Smalltalk Programmers Design session. It discussed some basic elements of design of Smalltalk programs which are often missed or misused by developers. The discussion centred around Abstract Classes and when/how to subclass and how to use polymorphism in that hierarchy. Abstract classes as interfaces, where the interface is defined in the superclass and implemented in the subclass and the superclass. This is in contrast to the concept of using subclasses to add state and behaviour to already existing state and behaviour. It was obvious that Bobby was not in support of adding to an existing class to get something new/different. I have not been in the Smalltalk community long enough to know the history of these two approaches and would have liked to have a longer discussion on the topic (Bobby was leaving for other destinations).
This session delved into the use of internal objects in a Smalltalk system, to a depth that, in my opinion, turned it into an academic exercise rather than a presentation of useful ideas. However, taken as a set of extremes which can be brought back to reality, it did give some ideas of the kinds of things that might be done in a Smalltalk system. Some of the less extreme items discussed were:
Many have used some if not all of the above, hopefully not at the application level, but perhaps at the framework level. Some more controversial items included:
This was originally scheduled as "Ralph Johnson", the head of the Smalltalk effort at UIUC, but he was in fact off negotiating some kind of deal in Redmond, so Don Roberts one of his Grad Students did the presentation. Don Roberts is the author (or current author) of the Refactoring Browser. Basically, this session talked about Frameworks. What are they? Do you have one? Do you even know if you have one? Should you have one? And other similar questions. A typical situation that would lead to a Framework:
If a framework does not make life easier, then it probably shouldn't be a framework. Having talked for a while about frameworks, he then went on the describe HotDraw which is a classic framework on which drawing applications of many kinds can be built (note that HotDraw comes with VW3.0). For any interested parties, he also gave a demo and short talk about the latest version of the Refactoring Browser (following the session). He said the latest version was on the web site, but I could not find and have not gone after it yet (I don't think the one in the archive is as recent as the one he was showing).
Although this session was basically what I thought it was going to be (a discussion of accessing non-Smalltalk code and applications), it was 100% IBM VisualAge Smalltalk with no references to any other. This was considerably narrower than any other session I attended all of which specifically addressed to varying extents, each of the other major Smalltalks. The main focus
here was on the use of Primitives (primitives are no longer available
at all in VisualWorks). However, some of the basic ideas were of
general interest. |
|
Last
Updated: Tuesday, August 7, 2007
|