As a newbie to Smalltalk, I was quite surprised to read in an article by DanIngalls
in the Smalltalk issue of Byte (Aug. 1981, p. 286 ff.) the following words:
- As might be expected, work remains to be done on Smalltalk. [...] For example, the Smalltalk-80 system falls short in its factoring because it supports only hierarchical inheritance. Future Smalltalk systems will generalize this model to arbitrary (multiple) inheritance. Also, message protocols have not been formalized. The organization provides for protocols, but it is currently only a matter of style for protocols to be consistent from one class to another. This can be remedied easily by providing proper protocol objects that can be consistently shared. This will then allow formal typing of variables by protocol without losing the advantages of polymorphism. [...]
Question: Imagine you were given the task of defining "Smalltalk-99". Which, if any, features would you
add to Smalltalk?
Name spaces. And that's low priority. The other big things it needs aren't language-related, they're things like 20th-century browsers, built-in refactoring browsers, decent code management. In short, stuff you can borrow or buy already. I'd specifically not add multiple inheritance, because I believe it adds too much complexity and is an irresistible temptation to idiots like me to mess with it. I don't much care about protocols or formal typing. Of course, I've used it only for small projects like C3, with only a couple of thousand classes ... -- RonJeffries
After Dan Ingalls wrote that, he implemented multiple inheritance for Smalltalk, and described it in a POPL paper with Alan Borning. Lots of other people have implemented multiple inheritance for Smalltalk. It is widely regarded as not needed for Smalltalk, and when Dan Ingalls talks about what he would like to add to Smalltalk, he still talks about a protocol-oriented type system, but does not mention multiple inheritance.
I agree with RonJeffries
that name spaces are the one language feature most needed. I would give it higher priority than Ron. -- RalphJohnson
What has been the approach so far in adding types to Smalltalk? Have the schemes tried to emulate the type-is-class approach of other languages? Where can one find out about TypedSmalltalk
Smalltalk may be in a local maxima. Other languages have features I like very much, but I wouldn't want to add those to Smalltalk because they would break it. -- DaveHarris
Adding (safe) assertions to Smalltalk is much harder than it sounds. Consider what happens in C when you do:
Now if you compile with -DNDEBUG, i won't be incremented by the assertion. Just imagine if you added assertions or dbc to Smalltalk. An expression evaluation could call a method that changes the state of the thing being tested. (In other words, you can introduce HeisenBug
s.) To add assertions with no fear of HeisenBug
s, you need to introduce Eiffel-style queries. In Smalltalk, that means adding a new programming construct - a method that can't change the state of the system. Given the fact that "everything is an object" this new construct will have to fit into the existing hierarchy of classes that form the core of the system.
No - Eiffel itself doesn't have Eiffel-style queries. There is nothing to stop an Eiffel query from changing the state of the system other than programmer self-discipline. (This is because of things like caches, which change the physical state but not the logical state, and because the compiler can't tell the difference between physical and logical changes.) If Eiffel doesn't have a special construct, Smalltalk doesn't need one either.
Another way of putting it is that we already use Eiffel-style queries all the time in Smalltalk. Consider methods like #collect:, #select: etc. Much of the collection protocol is side-effect-free, and safe to use in assertions.
Incidentally, C++ does
have a construct, namely const
as applied to methods. It would make sense for a C++ assertion mechanism only to allow calls to const functions. Of course, you could still get HeisenBug
s by using mutable or const_cast<> or other workarounds. (The difference between logical and physical state is the reason these workarounds were added to C++.) -- DaveHarris
It would be nice if Smalltalk code were defined in text files that lived in the filesystem instead
of in a memory image that is indecipherable! Source code management would then be a non-issue -
just use CVS (good for most) or new-breed (opencm, subversion, arch, vesta, etc). -- StevenShaw
The code is stored in text files, the sources and the change file contain it, the image isn't for the code, it's for the instances created from the code, the object memory.
doesn't need MultipleInheritanceInSmalltalk
because Smalltalk has loose typing.
To achieve polymorphic behavior in C++ you must
call virtual functions by pointer or reference from a common base class.
This forces you to use lots of inheritance and abstract/base/interface classes.
In Smalltalk, any two classes that respond appropriately to the some common set of message signatures are polymorphic -- you can substitute one for the other.
-- JeffGrigg (...still a Smalltalk beginner, after all these years.)
A nice model for composing/sharing behaviour across classes is Traits http://www.iam.unibe.ch/~scg/Research/Traits/
available in Sqeak dev images from at least 3.10
Interfaces - like in Java?
"Adding Dynamic Interfaces to Smalltalk" JOT May-June 2002
Interfaces are needed in a statically typed system only to gain PolyMorphism
, Smalltalk already has polymorphism at the method level by default. Interfaces have no place in a dynamic type system, hell, interfaces are trying to simulate a dynamic type system in the first place.
Is Smalltalk over-full? What would you delete?
Top of my list would be classes. Move to a prototype-based system like Self.
Also, be sure not to miss the LanguagePissingMatch. ;->