What If..... Strong Types

[Huaiyu Zhu]

Don Garrett <garrett at bgb.cc> wrote:
>   I'm not suggesting any real changes to any, only proposing a thought 
>experiment.
>
>   What if Python had been built from the start with strong types? And I mean 
>strong types, not strong typing. The distinction I am trying to draw is that 
>variables would not be typed, but that all types would have rigid interfaces.
>
>   Primarily, what if classes always had rigidly defined interfaces. I mean 
>that public members had to be declared to exist, and that methods couldn't be 
>modified on an instance. Private members could exist but would be really private.
>
>   All types would be classes (including ints and such). Amoung other things, 
>I would add the concepts of Interfaces, instanceof operators.
>
>   Local variables would not require declaration, and would work just like 
>today. Introspection would work, but be read-only.
>
>   My belief is that almost all the convenience of Python would be maintained, 
>but that compilation, optimization, and automated code analysis would be simpler.
>
>   I'm just wondering if the change would be good or bad. Would it really 
>break anything important in Python today? Would it prevent any common errors? 
>Would it help with automated code analysis (compilation and optimization 
>included) as much as I think it would?

What you are talking about is not strong types.  Python already has strong
types.  You are talking about interfaces, which is quite different from
classes.

Classes define a hierarchy of implementation, so that attributes of base
classes can be used in derived classes.

Interfaces define a hierarchy of requirements, so that a sub-"type" can be
used in places that require a base-"type".

They cannot be combined easily because the two hierarchies do not share the
same inheritance structure.

Example 1: You might want to define a class of file-like objects that shares
no implementation with builtin files.  You want just the interface.

Example 2: Mathematically a square is a kind of rectangle.  So anywhere a
rectangle is required, a square should do.  But for graphical classes it's
often better to code Rectangle as a subclass of Square, because it uses most
of the methods of Square, in addition to its own.  This is implementation.

Example 3: It is often necessary to require that an object is one of several
types, AFTER the types have been defined.  For example, you might code up a
Time class, whose __init__ accepts numbers (as seconds), strings (in the
common time format), and tuples (as hours, minutes and seconds).  If you
want to label all these as TimeData, it cannot be a base class for strings,
numbers and tuples, as these have already been defined.  

The relations of interfaces are often built from specific to general, in the
opposite direction of class inheritances.

We can conclude from these considerations that mixing the implementation
hierarchy with the requirement hierarchy is not a good general solution,
although it is sometime useful.

Java's interfaces and C++'s abstract classes re-uses the same inheritance
structure of implementation for interfaces.   Such interfaces are not as
useful as it could have been, while creating some additional problems.

To do it right, interfaces must have an inheritance hierarchy that is
separate from that of implementation.  It is possible to re-use the existing
class hierarchy for this purpose if done carefully in special cases, such as
Python's exception classes.  But a general type-hierarchy (serving as
interfaces) has to be separate from class-heirarchy.

Will it be beneficial to Python?  At least, it will allow many formal
correctness guarantees.  It will help compiling.  It will reduce much of
current type checking against implementational classes.  It will reduce the
computational burden of much of run time type checking.

How difficult would it be?  Well, it has to be optional.  It has to have an
inheritance syntax that is not confused with classes.  There need to be
syntax to specify requirements (such as with function arguments).  There
need to be syntax to specify invariance assertions.  The checking should
best be done at C-level, possibly in the compile stage, for the sake of
efficiency.  Last but not least, there need to be a good name beside the
word 'type', which is becoming similar to 'class' in Python now.

I think that once it is decided what it should look like, there are many
capable people who can actually implement it.

Huaiyu