The Droste Effect

Some of the drawings by M.C. Escher (notably this one) are known as Droste Effects. I have cited Escher's "Prentententoonstelling" because Escher expressly highlights the impossibility of his drawing: it's where he puts his signature.

Clique Space creates an environment which models that which is motivated to model. As such, it appears (at least to me) that Clique Space does in Java SE what Escher does in his lithographs. However, I think that my construction of this phenomenon is a necessary component to the concept, even though I did not realise this necessity was evident when I first conceived the core components that make up the Clique Space data model back in 2004.

I'll throw caution to the wind and talk about some Clique Space mechanics in this entry, because I think the phenomenon I am disclosing here is a priceless example of the power of Clique Space. In any rate, I'll be light on specifics so I might merely pique the reader's interest to the extent that they might want to get in contact with me. All contact is welcome, especially from those of us who have a lot of money.

The core data model of Clique Space includes the definition of seven Elements: the Sovereign, the Media and Mode Profiles, the Connection, the Affiliation, the Identity, and the Participant. All of these Elements are also qualia, and each Element except the Sovereign is a communicable quale.

Each Element instance is uniquely and universally identifiable: to keep to this intent, each Element class is paired with its own identifier class. Hence, all Element classes extend the "Element" class, and all identifier classes extend the "Identifier" class. Every class except the Sovereign implements the "CommunicableQuale" interface, and this interface includes an "asSignal" method which generates a specific signal (a copy of the associated identifier's value) when a given device wishes to transmit the fact that something has happened to the given communicable Element.

Creation of the identifier is delegated to the Element class's constructor. This is all good; the Element's constructor can use Java generics in some wonderful ways to call back to the subclass implementation, creating the type of identifier required. However, to do this, one observes the ejection of a nugget of impossibility inherent also in the drawings of Escher. This nugget is the self-referential nature of how the implementation of those communicable Elements effects the extension of the Element class to implement the Sovereign.

To keep a long story short (and the implementation specifics safely distant), all Elements (including the Sovereign) must extend the "Element" class. All Elements (except the Sovereign) are communicable Elements, and yet even the Sovereign, though it does not use the same call-back mechanism to create its identifier, must provide something (let's call it a mechanism that caps the naked contradiction) to insert as the thing that implements the communicable side of a communicable Element's nature.

The solution to this gordian knot is to use Java generics to create the most elegant logical relationships: all Elements except the Sovereign indicate themselves as their communicable quale. The Sovereign, possessing no ability to be communicated, specifies a dummy (unimplemented because it is never called) interface that covers the naked contradiction. I have likened this particular interface to be like the presence of Mr Escher's signature in his "Prentententoonstelling" image, and have thus called this interface the "Escher".

Et voila:

public interface Escher<
 CL extends Clique<CL,I,P>,
 I extends Identity<CL,I,P>,
 P extends Participant<CL,I,P>>
extends CommunicableQuale<CL,I,P,Escher<CL,I,P>>{/*Declare nothing.*/}

Hence, I believe that at the moment, the "Escher" interface is an effective mechanism that pays a dry reference to the universality of the phenomenon that I am attempting to address.