Lambda the Ultimate

b) do something silly like letting somebody else specify the implementation of a friend.

There is something to be said about keeping related code in the same source file ;)
Who knows who will revisit your code after you wrote it?

It always seemed to me that sorting code into files is a little odd. Especially since the ways that we need to access definitions are much more like searches than reading a book.

I think Visual Age IDEs used to show you a more fragment (by method) view of the source code. It was a little annoying because sometimes I really do just like to scroll through the whole file to try to get the gestalt of things, and because I'm relatively good at maps+directions so once I know the layout of a file I can find what I want by direct navigation rather than search.

Basically the idea of One Way To Do It when it comes to viewing code is probably wrong; it would be nice to enable many different views of it. Like, sometimes I want to see the subclass as if it had all the parent class code inlined in it.

IIRC, the Eiffel tools from Betrand Meyer's company allow four views of a class--the product of two orthogonal parameters:

* Whether all features (including private one) were shown, or the public interface only

and

* Whether or not the "resulting" class (containing all base class features not overridden or renamed), or just the class definition itself (showing only changes from the base classes)

Of course, such a feature is not technically limited to Eiffel.

In many OO languages, there arenot one but two hierarchies present: The inheritance hierarchy (which is often not a hierarchy but a DAG, in OO languages with multiple inheritance), and the scoping hierarchy (which remains tree-structured FTMP; though languages with delegation may also exhibit DAG-structure here as well).

I'm not aware of any languages in which visibility is based on the relational model. I'm sufficiently unfamiliar with "network databases" (other than RDBMS dogma that they are bad) to comment there; though capabilities (you can see things that you hold references to; there is no global ambient authority available through queries over a namespace or a set of relations) might suffice for an example of a "network model".

I'm not sure that a full-blown relational model (or a Prolog-style inference model, etc.) would be all that beneficial--such a thing might well be harder to specify and/or make secure rather than easier. What is the use case for such a thing?

Partly just a thought experiment. But, there are times when I want some part of something exposed to some part of something else, and in Java/C# I guess it would generally require either opening up everything, or making various adapter classes. Neither is an attractive option.

On the other hand, I do wonder if a relational visiblity system would simply lead to a rat's nest of completely non-un-tangle-able code.

lets you expose all of something to part of something else; though the "something else" is limited to either an entire class (which is often too coarse), or a list of specific methods within that class.

Friend does not, however, let you open up only part of a class's implementation to the designated friend--any class/method declared a friend has access to the entire stinking class

You can do that, albeit clumsily, in Java by resorting to the (default) "package" visibility.