Lambda the Ultimate

Actually I meant the paper "Object-Oriented Composition Untangled."

Object-oriented languages come with pre-defined composition mechanisms ... characterized by a certain set of composition properties, which do not themselves individually exist as abstractions at the language level. However, often non-standard composition semantics is needed.... Such non-standard semantics are simulated by complicated architectures that are sensitive to requirement changes and cannot easily be adapted without invalidating existing clients. In this paper, we propose compound references, a new abstraction for object references, that allows us to provide explicit linguistic means for expressing and combining individual composition properties on-demand. The model is statically typed and allows the programmer to express a seamless spectrum of composition semantics in the interval between object composition and inheritance. The resulting programs are better understandable, due to explicitly expressed design decisions, and less sensitive to requirement changes.

We may replace "limited" with "controlled" or "well-behaved", of course :-)

I am amazed to see a discussion about compound references here ;-)

The important issue about compound references is that their are transparent, i.e., the programmer does not know that his reference is actually a compound reference with more than one level of indirection. This is similar to an email redirection service - a user sending an email to a redirection service does not need to be aware of the redirection. If you use functions, pointers-to-pointers etc., you always have the additional step of function evaluation and pointer dereferencing; that is, the redirection is not transparent.

Is this just a syntactic transparency, as in C++, eh, references?

I mean, if you have a function

void swap(T& t1, T& t2);

and a client code

T a;
T b;
swap(a, b);

syntactically client is unaware of the fact that swap() needs references as opposed to values. At the object-code level, I think, client code still looks different for call-by-reference and call-by-value invocations. Probably I am talking about open-world-transparency vs closed-world-transparency here :-)

My naive understanding is that either client code is aware of by-referenceness of arguments or the identity of the object referenced by compound reference may become quite fuzzy... (for me)

I am not sure whether I am not just asking the author to become a visiting professor in this thread :-)

And yes, I agree that OO composition is tangled. Not sure, which one is not. My current favorites are mixins/traits (yes, OO), but people keep saying they are way too complicated... Go figure :-(

Apologies for the confusion but I was chasing a moving target. That particular paper has different callout on KO's home page than its actual title.

Apologies for the confusion

Consider the code in Java with compound references:

Person jack = ...
final Account ubsAccount = new Account("UBS", "12345");
final Account dbAccount = new Account("Deutsche Bank", "54321");
jack.setAccount(ubsAccount);
final Account jacksAccount = jack.getPersonsAccount();


assert(dbAccount != ubsAccount);
assert(jacksAccount == ubsAccount);


jack.setAccount(dbAccount);


assert(dbAccount != ubsAccount);
assert(jacksAccount == dbAccount);

To me, the first two asserts seem to contradict the second two (intuitively), taking into consideration finals. As I said, either we have transparency or intuitive identities, I cannot see both. Help me out of this, I am sure I trapped myself.

jacksAccount is not tail-identical to usbAccount, but it is head-identical to it.

After the setAccount-call, jacksAccount is not tail-identical to dbAccount, but it is head-identical to it.

What is probably slightly confusing here is that the identity relation can change without re-assigning the variables. With head-identity you preserve the invariant that the identity relation cannot change "behind the scenes", whereas tail identity is more dynamic but does not preserve this invariant.

Hope that helps.

By the way - Towards a Composition Taxonomy is very interesting, and there is no joke in this sentence, despite my silly character. It states some things that people already knew, but never called by names (at least I never saw them doing that), as well as some completely new to me. And it does that in 16 pages and several figures. I wonder, how came I never saw that paper before - why not publishing it at CiteSeer?

This behavior is very similar to Prolog's logic variables. CTM calls them dataflow variables because they are what makes dataflow concurrency possible. Dataflow variables can be used before they're bound, which is at the heart of dataflow concurrency. When using a dataflow variable in an operation that needs a value, synchronization is implicit: the operation will block until the variable is bound to a value. This idea has a long history: it comes from concurrent logic programming in the early 1980s. Henri Bal et al [Computing Surveys Sep. 89] call logic variables "spectacularly expressive" when used in concurrent programming.

Can you give a comparison of compound references and logic variables?