?

Log in

No account? Create an account
Who, me? [userpic]

Shapes on the brain

November 24th, 2008 (04:10 pm)
current mood: bemused

OOP researchers have shapes on the brain.

I'm reading a paper on traits, which the authors are proposing as an alternative to multiple inheritance and mixins. It all seems sane; it deals with the diamond inheritance problem by separating state from code. And then, on page 7, they finally mention examples...and what sort of examples do you suppose they use?

(In Unison: SHAPES!)

Right. Shapes which can be drawn on a canvas, just like every OOP presentation you've ever seen. (Well. I suppose some use people instead. But let's ignore that for the moment.) And not just any shapes, but circles, which is about the simplest set of two-dimensional shapes you can come up with. It's as if the authors (four of them, on two continents) decided that, if they wanted to be iconoclastic about something substantial, they'd better be traditional where they could...and then went overboard, to the point where their example is so trivial it can't possibly convince anybody.

Comments

Posted by: C. Virtue (cvirtue)
Posted at: November 24th, 2008 10:20 pm (UTC)

What does OOP mean in this context?

Posted by: metahacker (metahacker)
Posted at: November 24th, 2008 11:10 pm (UTC)
miracle

Object oriented programming. A way of writing programs that looks at the properties of things ('objects'), and how those sets of properties are shared across some objects ('classes' of objects).

The usual, overused example is a "Shape", y'know, cause shapes have things like an area, a circumference, etc. And some shapes have a specific number of sides, but other shapes don't (e.g. a circle or a blob), so you start talking about classes of shapes ("polygons" vs. "non-polygons", let's say), and before you know it I'm teaching OOP 101.

Posted by: C. Virtue (cvirtue)
Posted at: November 25th, 2008 12:45 am (UTC)

Aha! Thanks!

Posted by: metahacker (metahacker)
Posted at: November 24th, 2008 11:11 pm (UTC)
keys

There's some mileage in using the example everyone knows. Alice and Bob get an awful lot of press in crypto circles. ;)

On the flip side, sticking with shapes always sticks in my craw, because no one seems to go into enough depth to get to the rich and annoying bits of complexity that really teach you OOP...

Posted by: Who, me? (metageek)
Posted at: November 25th, 2008 01:12 am (UTC)

Exactly. Starting off your presentation with shapes is like holding up a giant sign saying "I'm not going to go into details."

Posted by: Justin du Coeur (jducoeur)
Posted at: December 2nd, 2008 07:40 pm (UTC)

Hmm. Interesting -- I'm currently reading into traits in a very different context. I'm seriously considering switching the main dev language for CommYou over to Scala, on the grounds that Java has irritated me to the point where I can't cope any more. Traits are a key concept in Scala. (Although, to be fair, I don't know the literature well enough to know whether what they call "traits" are precisely what you're thinking of -- they explicitly are using them to implement mixins.)

Anyway, I'm slowly making my way through their "guided tour", which uses a bunch of examples, but the one that seems to be showing the best expressive power is graphs -- they're showing things like how to define a graph abstraction, subclassing directed graphs out of that, subclassing more semantically rich graphs from there, defining nodes that cross graphs, and stuff like that. It's proving to be a good example, and is driving home that Scala is disconcertingly powerful, containing not only all the usual OOP concepts but a bunch I've never seen before. (Like "with", which lets you specify that this object must satisfy multiple traits...)

Posted by: Who, me? (metageek)
Posted at: December 2nd, 2008 08:43 pm (UTC)
Slightly different traits

Although, to be fair, I don't know the literature well enough to know whether what they call "traits" are precisely what you're thinking of

Almost, but not quite—Scala traits can have data members. In the paper I was reading, that was forbidden, on the grounds that data members exacerbate the diamond problem.

In terms of C++ (chosen because it has multiple inheritance), the trait concept I was reading about can be summarized like this:

  • A trait is a class. But hereafter we'll say "class" to mean "class which is not a trait".
  • A trait cannot have data members.
  • A trait T exports some methods, E(T) and requires others, R(T). (Given a sensible compiler, R(T) can be inferred.)
  • Two traits A and B can be composed into AB.
    • E(AB)=E(A)E(B)
    • R(AB)=(R(A)R(B)) - (E(A)E(B))
    • E(A) and E(B) must be disjoint.
  • A trait can inherit from a parent trait.
    • The child trait may restrict some of the methods exported by its parent (in C++ terms, making them private).
    • Restrictions are how you get around the "exports must be disjoint" problem. If A and B both export method M, define C as a child of A, restricting M, and then you can define CB instead of AB.
  • A class can inherit from zero or one class and zero or one trait.
    • Instead of inheriting from N traits, you have to compose them (pairwise) and inherit from the result.
    • If class C inherits from trait T, then C must have an implementation for every method M in R(T).

I don't know whether this definition is common in the academic literature; this is the only thing I've read on traits. Either way, it doesn't surprise me that Scala is less strict than this. This version is designed specifically to prevent the sort of surprises you get from multiple inheritance, and I think it probably goes too far. Scala's traits are more pragmatic.

a bunch of examples, but the one that seems to be showing the best expressive power is graphs

Interesting; I should read that. I'm not likely to take up with Scala (the JVM is a bit of an obstacle for me), but it sounds like it's got good ideas.

7 Read Comments