Tools that provide "closed" view of open/extensible abstractions?

What is the state of the art in tool support for looking at a codebase composed of open abstractions extended by independent modules, through a "lens" that allows programmers to see the final inter-dependent code as if all the abstractions were closed?

I'm thinking of this question in the context of ideas like the "Independently Extensible Solutions to the Expression Problem" paper. Open abstractions are great in that you can add new functionality without disturbing an existing, working codebase. The down-side is that open abstractions can end up obscuring the structure and control flow of the program that actually runs. When it comes time to debug a program, or diagnose performance issues, it really helps to view/treat a system as closed.

Coming from a performance-oriented world (real-time rendering, games, and GPU compute), this is a common criticism I hear of virtual functions in C++: you need to know about every possible implementer of a virtual function before you have any idea what actually happens at a call site. You can't even intercept "all calls to this particular virtual function" in your debugger.

It almost seems like there is a correspondence between the per-feature modules introduced in something like the "independently extensible" work, and changelists/patches that are shared in a distributed version control system. Each of these approaches allows a discrete feature to be packaged up, and then applied to a codebase. Sometimes you want to see the codebase in terms of a set of composed features/changes, which can be added/removed/reordered easily, and other times you want to see it as a single crystallized artifact that results from "squashing" a set of changes.

Another workable UI metaphor would be the way that layers work in, e.g., Photoshop. Your primary view of a document is the composition of all the active layers, but you can still target edits toward particular layers, or toggle their visibility.

There is Don Batori's work

There is Don Batori's work on C++ mixin layers, which might be similar to what your looking for. Also, family polymorphism via virtual classes allows one to develop their classes in lock step...you can simulate these in most languages that support mixins; but these days I use interfaces and partial classes in C#.

Also, consider subject-oriented programming.

By Sean McDirmid at Wed, 2013-07-10 21:49 | login or register to post comments

Thanks for the references

Unless I'm missing something, those all appear to be alternative approaches to the problem of expressing a program as a composition of separate modules (which is what I'm taking as the stating point), whereas I'm interested in the prospect of tools that let me view (and hopefully edit) the "post-composition" program directly, when it suits me.

There are fragments of this in IDEs and debuggers for OO languages. I can view a class hierarchy that shows me the "closed" result of inheritance, and I can typically browse all implementations of a given virtual function. Inside the C# debugger, both inheritance and partial classes are "flattened" away so that I see all the facets of the composed object in one place.

These flattened/composed views of the program are typically treated as secondary to the primary view that is the source code decomposition into files and/or modules (Smalltalk's class browser being a kind of exception).

I'm thinking of something like a tool that lets me declare different variants of an open sum type in different files/modules, when that is the view that serves me, but which at the press of a button allows me to view and edit the "composed" data type declaration all in one place.

That is, rather than argue over which decomposition of a program is best, why not let me toggle between multiple decompositions based on what suits me at the moment?

By Tess Foley at Wed, 2013-07-10 23:48 | login or register to post comments

I believe their is some

I believe their is some visualization and separation work on layers in the modularity (aka aspect-oriented programming), especially from the Bern people. Maybe try:

http://scg.unibe.ch/archive/papers/Nier05aNamespaces.pdf

http://www.research.ibm.com/people/w/wim/oopsla2001/papers/lanza.pdf

By Sean McDirmid at Thu, 2013-07-11 03:37 | login or register to post comments

In jiazzi, we also had the

In jiazzi, we also had the notion of atomic (feature based) units and composing compound units. You still could not see the flattened class, but...the compound units gave you an idea of what was composed at least. The reason I brought up the above work is that, unlike Wadler's solution, our solutions (like jiazzi) were able to reason about explicit multi-class crosscuts.

What you really want is a projective bi-directional editor with different modularization views. It just happens that I'm building the editor part, perhaps it's time to work on the differently organized editable views again.

By Sean McDirmid at Thu, 2013-07-11 12:22 | login or register to post comments

not just read-views

an attempt at food for thought: why do we split things into different files, when we want to see the sum total at the end? maybe i want to edit things as the sum closed total, but with some way of saying how it then gets split up.

By raould at Fri, 2013-07-12 17:23 | login or register to post comments

Fluid AOP?

I think what you're talking is, roughly speaking, what Gregor Kiczales called "fluid AOP", on-the-fly re-modularisation. Here are a couple of links:

Fluid AOP Join Point Models
Fluid AOP : task-specific modularity (Terry Hon's masters thesis)

But you won't find much on it, as it's a hard problem, and I don't think these people had any particular foundational insights about how to make it any easier.

By Roly Perera at Thu, 2013-07-11 06:51 | login or register to post comments

I pursued this problem for a

I pursued this problem for a while, some five or six years ago. The really, really hard problem is editing views. But read-only views, especially lossy views (i.e. that focus on specific relationships but don't represent the full behavior of the system) are quite feasible. Read-only views are potentially useful for debugging; I didn't get quite so far as implementing anything.

By dmbarbour at Thu, 2013-07-11 07:04 | login or register to post comments

Wasn't Simonyi's intentional

Wasn't Simonyi's intentional programming supposed to deal with this also?

By Sean McDirmid at Thu, 2013-07-11 10:58 | login or register to post comments

Intentional programming does

Intentional programming does have some designs that look like they were intended to enable flexible views. But, as best I can tell, all they accomplish is to avoid redundant parsing (by shifting the canonical rep to XML). I do not recall the challenges involved with cross-module views being addressed. (OTOH, I did not follow intentional programming after its debut.)

Personally, I think this is more an IDE feature. Language design can aid it a bit, but I would bet that cross-module views can be supported at useful and usable qualities for many popular existing languages.

By dmbarbour at Thu, 2013-07-11 13:26 | login or register to post comments

Lambda the Ultimate

User login

Navigation