The Capability systems and models variations date since middle half 60’s. Despite being classical, this model still needs to conquer widespread use today, due its straightforward reasoning properties and secure communication patterns (even among mutually suspicious parties). For those who don’t know that model, this post suits well as a complete introduction and essay (in some sense) about Capabilities, related terms/concepts and design issues. So, let’s explore this Capability world together!

Today we’ll show you guys an interesting concept that we have developed, with the sole intent to provide a fine-grained implicit delegation mechanism. This concept is bullet-proof against the diamond problem and the fragile base-class problem. Traits, talents and mixins also provide the solution for the diamond problem, but are prone to the fragile base-class problem¹ besides their own issues, e.g, the problem of external method renaming² . We will call that concept as First-Class Delegation Links from now on, and so we argue why our concept is safe against such problems.

This post is just a suggestion for language designers of Object-oriented systems. Nothing really new except my new approach to see objects. Sorry, Alan Kay, but the main concept of OOP doesn’t lie with Message-Passing, but mostly with all the sort of Relationships among objects. These relations are already well-known: Inheritance, Delegation, Composition, Ownership, Cloning, Message-Passing (yes, it also counts) and so on.

In my first post, I want to discuss how interestingly delegation can be thought in terms of object structure. My major reference here is the paper Delegation as a Sharing Relation: Characterization and Interpretation (made by Daniel Bardou). But, first and foremost, let’s discuss what is intrinsic to all object structures.