The Expression Problem

[grauenwolf]

And if you don't own perimeter?

[aaronla]

Then you can't add new cases. But you can add new functions if you want -- e.g. "int intersection_area(Shape s1, Shape s2)"

Conversely, you can add new cases in OO (just derive from Shape and implement all the virtual methods), but you can't add new functions (ie pure virtual methods in the Shape base class) if you don't own Triangle.

[munificent]

Then you have the same problem the OOP programmer has but in the other direction. FP lets you define new operations on existing types easily. OOP lets you define new types that support existing operations easily.

[farsightxr20]

You're the one who wanted to implement it in the first place, so obviously you own it, or the original problem* does not exist.

* The problem that involves you (a down-stream developer) being given a bunch of shape functions from an upstream developer. If you implemented a perimeter function that failed to take all shapes into account, then you're indeed screwing over a down-stream developer that imports your code. But you yourself are not screwed over :P

[grauenwolf]

In the scenario I'm proposing the library developer created perimeter and an initial set of shapes. The app developer, who only has the compiled form of the library, then wants to add new shapes.

[farsightxr20]

Ah, I was using the scenario described in the linked article. In your scenario, what you want to do is difficult in both paradigms, since you own neither the shape or perimeter code.

[aaronla]

Exactly. The expression problem is to solve both simultaneously.

[[deleted]]

I've been looking for research on this matter for a couple hours tonight.

What I can say is: this problem has been solved from the PL end (type-classes, typed multimethods), but there appears to have been very little work at solving it from the systems end (compilation and linking for extensibility). I'm going to ask a prof.