Typing system vs. Java

[Peter Mayne]

"Bengt Richter" <bokr at accessone.com> wrote in message
news:3b6c3e72.1263271428 at wa.news.verio.net...
> On Sat, 04 Aug 2001 17:03:05 GMT, Courageous <jkraska1 at san.rr.com> wrote:
>
> >Although I was thinking about about something which might be useful.
> >What if Python were to support a type consistency check on containers?
> >
> >>>> mylist = [1,2,"alpha"]!
> >Type Consistency Error:
> >>>>
> >
> >Note the exclamation point.
> >
> assert(type(mylist) in (type(()),type([])) and \
>   len([x for x in mylist if type(x)!=type(mylist[0])])==0)
>
> Would you use it often enough to warrant a language change?
>
> OTOH, if '!' were a unary postfix operator that you could define ... ;-)
>
> def __operator__!(mylist):
>     return type(mylist) in (type(()),type([])) and \
>   len([x for x in mylist if type(x)!=type(mylist[0])])==0)
>

There may be another way of doing this, which is hopefully more general.

Imagine that __add__ for list objects has __precondition__ and
__postcondition__ attributes. (By default, these simply return.)

To implement a homogenous list (ignore weird syntax where it occurs):

def __add__.__precondition__(self, other):
    """Ensure that a list only contains elements of a single type."""
    if len(self)==0:
        return
    elif type(self[0])==type(other):
        return
    raise NotHomogenousException

Now, whenever you do "c = c + [e]", the statement will only execute if the
precondition is met. (Obviously, all the different ways of building a list
must be covered.)

Let's extend this idea. Call a precondition/postcondition pair a constraint,
implement it in a class, and apply it to the list class.

class HomogenousConstraint(BaseConstraint):
    def __precondition__(self, other):
        # As above
        # We inherit __postcondition__, which just returns.

list.__constraint__[] += HomogenousConstraint()

(Don't pick holes in the syntax, I'm just trying to get the concept across.)

Note that __constraint__ is an attribute, so we don't have to subclass the
list type. Note also that __constraint__ is a list, because a class could
have multiple constraints. Now the constraint is applied to all operations
on instances of the class. (I don't know how, I'm a loony.) Now you can say

def myMethod(self, param: HomogenousConstraint)
    # etc etc

safe in the knowledge that param is homogenous. The compiler (bytecode or
otherwise) needs merely to check that the class of which param is an
instance has HomogenousConstraint as one of its constraints. If it doesn't,
the exception is raised.

Because a constraint is just more code, it can say things like "do I
implement these methods?", and we have something that looks suspiciously
like an interface (in the Java sense), thus providing Alex Martelli with a
way of saying "I require that this parameter looks like a filename, or an
object that implements the following subset of a file's functionality". And
because this can be a compile-time check, a "MustImplementSeek" exception
happens at compile-time.

There's some overhead when a constraint is involved, but constraints aren't
mandatory, as static type checking would be. Constraints need only be used
when a package/class author requires them. (Thus, backward compatibility.)

HomogenousConstraint is a constraint that might be used a lot, so it might
be predefined in the standard library, and/or implemented in C for
(ruthless) efficiency. Other more complicated constraints (such as checking
that even elements of lists are odd numbers, for instance) can be provided
in packages as appropriate.

So, our two weapons are programming with invariants and compile-time type
checking (but only where we want them) ... and interfaces. Amongst our
weaponry are such elements as invariants and type checking and backward
compatibility and an almost fanatical devotion to the BDFL.

And nice red uniforms.

PJDM
--
Peter Mayne
IBM GSA (but the opinions are mine)
Canberra, ACT, Australia
This post is covered by Sturgeon's Law.