Structural subtyping

• To: "Gary T. Leavens" <leavens@cs.iastate.edu>
• Subject: Structural subtyping
• From: "Robert O'Callahan" <roc+@cs.cmu.edu>
• Date: Tue, 23 Jun 1998 16:12:13 -0400
• CC: types@cs.indiana.edu
• Delivery-Date: Tue, 23 Jun 1998 15:15:09 -0500
• Organization: Carnegie Mellon University
• References: <199806201812.NAA23522@shovelnose.cs.indiana.edu>
• Reply-To: roc+@cs.cmu.edu

Gary T. Leavens wrote:
> That said, as a Java programmer, I've often wished for structural
> subtyping, as it's impossible to provide, for example, a reusable
> container class that relies on the elements implementing some
> interface.  You simply can't expect that other people would know enough
> to implement that interface ahead of time.

Structural subtyping may help, but I don't believe it's the answer. If the
original programmer didn't know enough to implement the interface, then you'll
be lucky if they used the right method name(s) and signatures. Naming
conventions and other stylistic conventions can help, but it's all still rather
fragile.

In general you're going to need glue code of some kind (sometimes just a
renaming mechanism, often more). I'd rather have support for convenient,
flexible and efficient glue in the language than structural subtyping (but both
would be nice). The parameterized extensions proposed by Flatt et al. in this
year's POPL might fit the bill.

Rob
-- 
[Robert O'Callahan (roc+@cs.cmu.edu)        4th year CMU SCS PhD
Home page: http://www.cs.cmu.edu/~roc       1 Samuel 15:22 ---
"But Samuel replied: "Does the Lord delight in burnt offerings and
sacrifices as much as in obeying the voice of the Lord? To obey is
better than sacrifice, and to heed is better than the fat of rams."]

• Prev: Re: Subject Reduction in Java -- without joins -- part 2
• Next: abstraction with subtyping & Overloading considered harmful
• Index(es):
  • Main
  • Thread