[cap-talk] Sensory entry points (start keys) in Gnosis like systems

[David Wagner]

Bill Frantz  wrote:
> I see I didn't adequately explain myself. These code examples 
> show the confusion.
> 
> The sense key provides a system enforced information diode. If 
> you only have a sense key to an object, you will only get 
> information from it. You will not be able to send information to it.

Nitpick: I find it hard to believe that this is the right way to think
about the definition of "sensory".  Technically, I suspect the formulation
should be in terms of mutating the object(s) referred to by the sensory
capability, rather than about sending information.

We send information to sensory/read-only objects all the time.  Consider,
for instance, a read-only/constant array.  To access the i-th element of
the array, we send it a message containing the index i.  That constitutes
sending information to the array object, however, no harm is done,
because the array indexing operation does not mutate the array object.

This is a minor nitpick.

> Consider the above example. If I code in some class somewhere:
> 
> public sendTo(ReadonlyCell c, Object data) {
>      T t = c.get();
>      t(data);
> }
> 
> I would have sent "data" to a place where the underlying Cell 
> object could read it (depending on the details of T), violating 
> the transitive read-only nature of an information diode. In 
> order to maintain this transitive read-only characteristic, the 
> get() operation would have to attenuate any write operations on 
> the t returned.

OK, sorry for the poor example.  To make my example obviously transitively
read-only, we can change the types around so that a Cell can only hold
values of an immutable type.  For example, take my example code and
replace every instance of T with String, so that Cells can only hold
Strings.  You get the following:

/** Holds a String. (mutable) */
public class StringHolder {
    private String member = null;
    public StringHolder() { }
    public String get() { return member; }
    public void set(String s) { member = s; }
}

/** Read-only view of a StringHolder. (sensory) */
public class ReadonlyStringHolder {
    private StringHolder<T> sh;
    public ReadonlyStringHolder(StringHolder h) { sh = h; }
    public String get() { return sh.get(); }
}

/** Read-only facet, with method that accepts a mutable parameter.
 * (still sensory) /
public class CoolerReadonlyStringHolder<T> {
    private StringHolder<T> sh;
    public CoolerReadonlyStringHolder(StringHolder h) { sh = h; }
    public String get() { return sh.get(); }
    public addContentsTo(Set<String> set) { set.add(this.get()); }
}

Do you like this example better?

Notice that CoolerReadonlyStringHolder is sensory: it is a read-only
facet on a StringHolder that allows clients to view the state of the
StringHolder, but not to mutate the StringHolder.  However, clients of a
CoolerReadonlyStringHolder can pass a mutable reference (to a Set) to it
via the addContentsTo() method.

This illustrates that, if I understand the meaning of "start keys" and
"sensory keys", Joe-E allows passing "start keys" to "sensory keys".
So it sounds to me like Joe-E does allow what MarkM wanted.

However, an important difference is that in Joe-E, the sensory restriction
is not enforced by the system; it is enforced by the programmer.
This gives more flexibility to the programmer, at the cost of requiring
extra effort from the programmer to define sensory facets.