🚀 go-pugleaf

In <1991Mar25.220525.11087@leland.Stanford.EDU>
hoelzle@leland.Stanford.EDU (urs hoelzle) writes:

>I think a few clarifications are in order because you're attacking on
>the wrong front, Joe:

I didn't intend to attack, just to make a point.  Heterogeneous
collections just happens to be one of my buttons.  Also, I shouldn't
have portrayed you as an "opponent of static typing" when you were
merely presenting one argument against static typing.

>2.  Here's why you want at least some form of heterogeneous collections:
>	
>	type T = "some type"
>	type SubT = "subtype of T"

>	procedure someProc(c: List[T])

>    I think that you'll agree with me that you'd like to use someProc with
>    a Collection[SubT], especially if someProc just iterates through the
>    list and sends 'foo' -- after all, every SubT "is a" T.  But as soon as
>    Lists are mutable (e.g. define insert(newElem: T)), the type system
>    won't let you do it because List[SubT] is *not* a subtype of List[T].

Aha!  There's no heterogeneous collection here.  There is, however, a
problem with the notion of subtyping for parameter conformance.  One
solution to an overly restrictive static type checker is to weaken the
static checking.  Another solution, however, would be a smarter
checker.

>    In a way, the problem exists because today's type systems are based
>    on what you *could* do to the list in someProc, not on what you actually
>    do.  

Indeed.  If I could provide more information about someProc, such as
the fact that it never attempts to modify its parameter (did I hear
someone cough "const"?), then even a simple type checker would be
happy to approve this operation.  Urs is correct that subtyping is NOT
the right way to express this relationship.  Subtyping is too strict a
conformance relation.

>3.  At least for rapid prototyping, your argument that "the type
>    hierarchy isn't perfect if this situation occurs" is invalid: you
>    *don't* want to rearrange lots of types just to try something
>    out.

This is a fairly strong argument.  A good programming environment
could go a long way toward neutralizing it, however.  I confess I'm
not aware of any that really eliminates all the effort involved in
making this kind of change.  On the other hand, I rely on static type
checking during my rapid prototyping.  It helps me to keep my mental
model synchronized with the code I'm actually manipulating.  I also
find that the more OOP I do, the less often that I make major changes
during prototyping without going all the way back to rethink the
design.  Maybe I'm fossilizing.

There are just opinions, of course, and your mileage may vary.

joe