We hold these truths to be self-evident, that all objects are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are sole access to their internal representation

An object-oriented language should provide encapsulation: an object should be able to protect its representation from unwanted external access. Programming languages provide a wide range of different encapsulation mechanisms: statically and dynamically checked; encapsulating names or objects; encapsulating within objects, or within classes, or within modules…

Grace will have a module system to support separate development and compilation: to manage coupling between different development units. The design is yet to be finalised (Ok, yet to be started) – but we are thinking along similar lines to Newspeak, gBeta, J&t or Ceylon in that it will be based on classes nested within objects.

But this large-scale encapsulation, within compilation units, doesn’t really address the key independence of objects in object-orientation: that each object should be independent, having sole access to its own internal representation. Now many object-oriented languages don’t in fact support this either. C++, C#, and Java have private and protected modifiers: but these restrict access within classes not objects: an instance of one class may access private or protected fields of any other instance of the same class — and for protected, of any subclasses as well.

For this reason, like Smalltalk, Ruby, and other languages, Grace will provide object-level encapsulation. Encapsulated names – methods and fields – will only be accessible from within the same object — i.e. by method requests on self. Again like Smalltalk and Ruby, encapsulation in Grace can depend on types (or classes) but not on static types or classes: we don’t want programmers to e.g. remove static types from their code just to get around encapsulation!

But there are a number of different options even within this design:

• private modifier – marks encapsulated attributes; no modifier means no encapsulation
• public or shared modifier – marks unencapsulated attributes; no modifier means no access except through self
• textual rules for encapsulation. In Go for example, names beginning with a Capital letter are public, names beginning with a lower-case letter are private. This convention is used throughout .Net programs – but so far we’ve been using a methods-as-lowercase convention, common in Java, Smalltalk, etc. This kind of implicit coding doesn’t work for code in non-Western alphabets that don’t distinguish between upper/lower case
• “reverse” textual rules – lower case is public, Upper Case is Private. At least this would work better with the Java convention – but that seems to be all it has going for it.
• sigils – use a non-alphabetic character to start all (encapsulated) identifiers. For example, any private const, var, or method must begin with an underscore (self._myStuff) — identifiers without underscores are public

There are only a few differences between these options: should the default be accessible (easier for novices to get started) or encapsulated (easier to learn good habits). Encoding encapsulation into the names (as in the last three options) makes their relationship with inheritance clearer, but changing visibility means changing names. On the other hand, modifiers on attributes decouples encapsulation status from the text of the name, but requires modifier-consistency rules across inheritance.

We’re in the process of working our way through these options (or at least thinking about them every so often). We’ll hope to have a decision by the time of the next Grace workshop (30 July, in Lancaster, after ECOOP).

If anyone has any random opinions (or even considered thoughts) on this, we’d love to hear them.