Smalltalk and Object Orientation: an Introduction - Free

to team development. At present if members of a development te am wish to share their work
they must file out (all) the relevant classes and methods from their own images and file in those
from their fellow workers. This can be problematic as well as cumbersome. This problem stems
from the very nature of the image in which all the “source code” is held and within which
development takes place. A fundamental change in the way that the image works is required.
• Typed variables : Smalltalk is a dynamically typed language. That is, a variable’s type is
determined by the type of object that it holds. This is all very well for rapid prototyping and for
small single user developments, however for large projects which must exist for significant
periods of time, this can result in disaster. For example, “type mismatches” cannot be detected at
compile time and will only manifest themselves at run time. This places a huge burden on testing
which must now catch such mismatches. In addition the performance of a dynamically typed
language can be lower than that of a statically typed lan guage as the run time system must now
perform various checks which could otherwise be performed at compile time.
• Improved exception management : At present Smalltalk possesses only very rudimentary
exception handling. If the developer has not defined how th e exception should be caught it is
merely presented to the user. This is acceptable for a single user/developer system, however for
delivered systems this is unacceptable. Even the facilities that are available are extremely
limited. For example, class lev el rather than block or method level support is required, such that
if a particular type of exception occurs anywhere within an instance of a class (or one of its
subclasses) then that exception is handled cleanly and in an appropriate manner.
• Private methods: In Smalltalk all methods are publicly available, that is any object can send a
message requesting that the receiving object perform any of the defined methods. In general
Smalltalk developers place those methods which are not intended for external use in method
protocols such as private (or private -). However this is only
convention and there is no system support for these “private” methods. Other object oriented
languages such as C++ and Java do support the definition of private and public methods. Indeed
these languages take the concept of private and public further. For example, in Java [van der
Linden 1996] there are a number of classes of access indicated by keywords:
1. public - world access.
2. protected - accessible to any object in the current package or any subclass in any package.
3. default - any class in the package (A Java package is a group of classes which are to be
bundled together. They are essentially the same as libraries in C++).
4. private protected - class / subclass access only.
5. private - accessible to the current class only.
Of course some of the above issues are being addressed by current research (for example [Feigenbaum
1995]) however there appears to be little interest in following this lead from the vendor community.
33.2.2 Technology issues
There are a number of technology based issues which will affect Smalltalk’s popularity in the coming
years. These are less related to Smalltalk itself and more to the way in which software is, and will be,
developed.
The majority of software today is developed for use on PCs running either Windows 95, Windows
NT or Windows 3.1. Therefore Smalltalk needs to be able to easily and simply interact with these
environments. For example, explicit support for OLE and dynamically linked libraries is a must.
In the future it is likely that the influence of the World Wide Web (or Web) and the internet will
continue to grow. Smalltalk vendors must provide facilities which will allow Smalltalk to take
advantage of t his (ParcPlace-Digitalk have already produced a product called VisualWave which is a
VisualWorks based Web server).
Object sharing and notification must be made significantly easier. CORBA (see [Ben -Natan 1995]
for a summary of the CORBA sta ndard and [Orfali et al 1995] for an excellent compendium of
distributed object technology including OLE, OpenDoc as well as CORBA) while providing a possible
infrastructure for such object sharing results in large cumbersome ORBs (CORBA st ands for the
Common Object Request Broker Architecture. It is a specification for an ORB (Object Request Broker)
which allows distributed objects within different systems to communicate. Simpler and easier to use
279