Guido> Using built-in classes as base classes for user-defined
Guido> classes poses several problems, most of which lie in the
Guido> realm of implementation. Several other OO languages can live
Guido> without this (C++, Modula-3), so I hope Python can as well.
The difficulties in the implementation doesn't mean much to the user
:-)
One promising thing with OO is that you can keep the name space small.
If you could build new types from the builtin the chance of
preserving the same name for similar operations would be greater.
A promising thing with small languages is that you don't have to learn
a lot of special purpose mumbo jumbo. This seems to be a good thing
for a script language since you'r not likely to use it everyday. But
the language also needs to have enough power so you'll easily express
what you want. The OO-things can give you more specialized powerful
objects which might still be used in the same way as builtin objects.
If that's possible you have won a part of the battle of complexity.
Overloading builtin operations can be viewed in the same light. If
adding two objects make sense then maybe "+" is a good way to express
that.
These things are contradictory but I'll suggest keeping the smallness
in favor for adding more power with special constructs. Treating the
builtin types just as user defined wouldn't it make the language
smaller and easier to comprehend?
Another convenient thing for a script language would be to have
unbound precision integer arithmetic.
Yours
%% Mats Lidell
etxmsll@juno.ericsson.se
"A man about to speak the truth should keep one foot in the stirrup."
-- Old Mongolian Saying