Late note (2018):
this page was originally written in the late 90s, and nothing has happened since. ST/X will not wait for these changes any longer and started to get extensions to fix those shortcomings.
This page lists things I would like to see in any upcoming Smalltalk language standard. Please feel free to send additional suggestions to the author for inclusion in this document.
Many organizations use various dialects of Smalltalk concurrently (today, mostly ParcPlace vs. DigiTalk or VisualAge). Reusing code between these dialects is especially difficult, since Smalltalk provides no facilities for conditional compilation.
Therefore, different versions of a classes methods cannot be easily kept in one sourcefile, making maintenance a nightmare.
With other Smalltalks like SmalltalkAgents, Enfin and Smalltalk/X appearing, things will become even worse. (late note 2020: some of them disappeared more or less; others appeared, such as Squeak and Pharo)
Smalltalk requires conditional compilation at least on a per method basis
(better yet: some kind of
#ifdef within a method).
A suggestion for per method conditional compilation is a construct like:
where "name of system" could be something like
"VV2.0", "STX" etc.
!MyClass methodsFor:'category' forSystem:'name of system'!
As a first step, systems should check and ignore methods (at fileIn time) which are not meant for them. However, to allow for all those versions to be at least edited and managed in a browser, methods for other systems should be read and kept in the class as hidden and/or non-executable methods.
Browser support for these has to be added.
Smalltalk/X already provides the required internal mechanisms
to implement such a scheme: methods can be declared as ignored.
These methods are visible on the browser level, but ignored with respect to
method lookup. The ST/X browser already handles those ignored methods;
they can be filed in and filed out just like any other method.
Adding a conditional ignore feature to this basic mechanism would be an easy task.
End of line comments are useful and a common standard is required.
"/ (double quote followed by slash)
which is backward compatible
with existing code (there has not been one class in all freeware classes
which failed to load due to this new comment syntax).
It has always been a pain, to comment a piece of code which contains comments. Although the above mentioned "End of line" comments are helpful and at least solve the problem of commenting-out code in the browser, it is still insufficient for documentation methods, if the code there shall contain comments (either EOL or regular comments).
ST/X supports token block comments, which start with
"<<token (double quote followed by two less-characters and a token word)
end ends until a line is encountered which starts with the token.
this is all commented
and may contain other "comments"
"/ end of line comments
ST-80 uses the "d"-character to mark double number literals;
i.e. "1.0" generates a float literal, while "1.0d" generates a double
VisualAge uses the "d" to mark Decimal number literals, which are (to add more confusion) called FixedPoint in both ST-80 and ST/X.
To make things more complicated: ST/X generates double floats for all number constants which contain a decimal point. In ST/X, the corresponding class is called Float.
(ST/X does support single precision floats, but those are called ShortFloat here).
The reason for ST/X doing things that way is to make things as easy is possible, when code is ported from other systems; Float is the one supported by any of them - therefore, this is the default here. In ST/X, Double is an alias for Float - to avoid trouble if anyone accesses this class explicitely.
There is definitely a need for a proper standard here.
There should be some way to put graphical or control characters into a string constant; similar to (for example) the way this is done in the C language, using a backslash as escape character.
Although such an extension is easy to implement, no standard exists
yet; and, worse, the backslash is already used to mark carriage returns
to be replaced by the
In ST/X, you can use the
which translates C-language like escape sequences. Currently, this translation
is done at execution time, but future versions of
the compilers will detect sends of this selector to a string constant
this translation at compile time
(but only, if the immutableArrays option is turned on).
The newer ST/X versions support C-style strings; but to not break backward compatibility,
they need a special prefix to the string constant. Regular string constants still behave
as usual, c-style strings are prefixed by a "c"-character.
c'foo\nbar\nbaz' defines a C-style literal string with embedded newline characters.
There should be some Smalltalk syntax for 16bit string constants.
ST/X supports both single- byte and multibyte string constants, and chooses whichever representation is required.
ST/X already includes a mechanism to define private classes
It would be nice to have a common language standard for this.
These are extremely useful to return multiple values in a structured way;
In Smalltalk, you'd have to either define a simple data-holding class,
or return a dictionary. Both are inconvenient.
An extended literal syntax might look like:
and a computed inline object like:
Both can be parsed and distinguished from eg. brace arrays or literal arrays.
bar: (1234 + a).
baz: Date today
ST/X supports such objects, where the object is kept in the literal array, and the set of their anon classes is remembered in a global dictionary and reused. The classes are simple data-holding classes only, providing getters and setters for computed objects, and getters only for their literals.
Although some vendors may not like this idea, a standard binary format (and of course: a standard bytecode representation) should definitely be added to all systems - this would allow code interchange the "java way".
Even if no common bytecode-encoding is possible,
an intermediate bytecode representation could be defined, which is translated
at load time to the particular implementation's encoding.
Technically, this should not be too difficult, since the various Smalltalk implementations bytecodes differ mostly in their encodings - less so in the semantic of the codes.
There should be a common UI framework, possibly with limited functionality, which could be mapped
onto the native framework. This could eg. be done by defining a simple spec format
(aka literal window spec as in VW or ST/X, or XML-like),
and dialect specific builders.
Currently users are more or less locked into their dialect on the UI side. Things look a little better on the model side, but there as well are pitfalls to expect.