Smalltalk and Object Orientation: an Introduction - Free

33. The Future for Object Technology
33.1 Introduction
This chapter is structured in the following manner: we first consider issues directly relating to the future
of the Smalltalk language and then the type of object oriented development toolkits which are, and will
be, available. We next consider the impact of the internet on object technology. We then briefly discuss
the development of object oriented databases and then address Smalltalk’s role as a training
environment for object technology before concluding by considering very briefly the future of object
technology over the next five years.
33.2 The Smalltalk language
The Smalltalk language is unlikely to change a great deal for the new ANSI standard being produced by
the X3J20 standard committee. This committee was formed in late 1993 and draws its members from
both the user and vendor communities. This standard is necessary as more and more vendors are
producing Smalltalk based development systems which, while similar, all possess (significant but
subtle) differences. Although the merger of the two largest Smalltalk vendors ParcPlace and Digitalk in
1996 could be seen as resulting in the creation of an enforce d standard, other vendors could still “go
their own way”.
However there are other aspects of the Smalltalk language which need to be addressed, some of
which are fundamental to Smalltalk and others of which are technology oriented. Each of these areas
will be considered below.
33.2.1 Smalltalk issues
There are a number of language issues which Smalltalk must address if it is to survive and prosper into
the next century. All of these are related to providing better support for large scale, commercially
critical systems. Such systems require:
• Non-interpreted implementations : All commercial version of Smalltalk rely on the use of a
virtual machine which executes byte codes. The byte codes are the “compiled” version of the
Smalltalk source cod e. This means that Smalltalk is compiled into an intermediate language
which is then “interpreted” by the virtual machine rather than being compiled into a native code.
The result is that Smalltalk does not produce a true executable image which generally r esults in
significant performance and memory overheads.
• Class-based version control : Within a software development project, different team members
will be developing different parts of the system. In many cases they will maintain their source
code using a source code control systems such as SCCS under UNIX. This means that all the
source code control operations are outside of the Smalltalk system and require external
intervention. For example, if a developer within a project using SCCS, wishes to see how an old
version of a class would interact with a set of newly defined classes, they must leave
VisualWorks, retrieve the old version of the class from SCCS, file it into VisualWorks, probably
having removed the newer version of the class from the image to ens ure that no additions
remain. When they have finished performing these tests they must then retrieve the new version
of the class. Such version control of classes and methods should be inherent to the development
environment rather than a third party after sales add-on.
• Team-based development support : Smalltalk was originally conceived as a language and
development environment for a single user. It therefore has inherent weaknesses when it comes
278